KVR Audio

WilliamK · Post by **WilliamK** » Mon Nov 25, 2013 12:37 pm

Indeed, can't use that code, sorry, but it is a mess due to the real-time aspect of things. The Flag Enum is still the best option here. But in any event, I will update the code to be more readable and easier to use.

WilliamK · Post by **WilliamK** » Mon Nov 25, 2013 7:42 pm

Ok, here we go, this is what I have finished up. Now I need to redo all modules codes before I can release the next beta + github updates. This will take a while, as it is a lot of changes. But at least it does look better now, and I still need to update some comments, but I will do this later on.

Yes, I'm still using some ugly Macros, but I really like those, hope you won't be too hard on me for this.

aciddose · Post by **aciddose** » Mon Nov 25, 2013 9:00 pm

Mega-paste again!

I have been keeping up to date on your changes via github so no need to paste. Actually the diff via github works great as I can see exactly what changed and when. (Oh, I see these aren't commited though. Have you considered using a branch? "Refactor" or something?)

Yes I was going to point out that since you're reading multiple flags per-sample, the most optimum method is the bool method also. That is why I pointed out it makes sense to pre-pack and unpack the flags when they're used either by host or plugin, and only do the pack/unpack once when the data is exchanged. That saves from multiple ANDs and extra code...

Although it requires a benchmark to really test which is faster since on x86 for example AND sets the flags directly and can be copied to a byte directly using a single opcode.

In the case that the host/plugin frequently changes the flags probably the most efficient method is to keep them packed.

WilliamK · Post by **WilliamK** » Tue Nov 26, 2013 9:46 am

Ok, I updated the Module SDK and most of the modules files including the Gain Example. I will update the other files now and also the PDF soon.

https://github.com/Wusik4000/Wusik_4000_SDK

I won't mess with the Modules SDK for now, so you are good to use it.

Ah, of course, this new SDK won't work with the current Wusik 4000, but I will release the next beta tomorrow.

WilliamK · Post by **WilliamK** » Tue Nov 26, 2013 12:13 pm

Just updated the docs (pdf) and also more modules. 70% done now...

WilliamK · Post by **WilliamK** » Tue Nov 26, 2013 7:03 pm

New Beta version (for now only the Windows files, the MAC files I will handle later this week)

November 26 1013 - Beta Version B0016

- Fixed bug when removing any instance of a project while still having another instance loaded up, the GUI would break, but not crash.
- Skin update: removed Icon support (was not been used)
- Module SDK changes
- Enums updated to be inside relevant classes
- Several other big updates, including better commenting and easier to understand classes.
- All Modules must be updated and recompiled with this new SDK in order to run on this new beta.

-----

Updated the public Module SDK (for C++ developers)
https://github.com/Wusik4000/Wusik_4000_SDK

WilliamK · Post by **WilliamK** » Wed Nov 27, 2013 10:50 am

Well, it was a heck load of work, now I will rest for a few...... minutes.

WilliamK · Post by **WilliamK** » Wed Nov 27, 2013 11:18 pm

And here is the link to the public beta files. (unrestricted)

http://www.wusik.com/ww/products/wusik-4000/public-beta

Any 3rd party developer will also receive a full copy of the product.

aciddose · Post by **aciddose** » Thu Nov 28, 2013 2:02 am

I would have already written something but unfortunately I've been very busy the last couple weeks. I hope I'll be able to do an envelope quickly some time in a week or two.

WilliamK · Post by **WilliamK** » Thu Nov 28, 2013 8:35 am

Great, good news them.

WilliamK · Post by **WilliamK** » Tue Dec 03, 2013 3:53 pm

Anyone else feels like trying out the SDK?

WilliamK · Post by **WilliamK** » Sat Dec 07, 2013 11:28 pm

Ok, so now is the time to manage sample handling. I'm working on several ideas for week now, but can't finish the design...

going mad at this...

So, here is a basic idea:

- A public open-source module that is stored under Extras handles sample loading and processing. It returns back to the host the sample data in an internal format.
- Multiple modules can be done, so if we want a new format, we could just add a new module, or update an existing module.
- The above opens up for 3rd party file-format converters. How? Well, let me see if I can explain better...

In the Extras folder, we would have multiple files named, let's say, SampleLoader001.dll, SampleLoader002.dll and so on.

The host sends to the first one: Hey, I have this file named c:\samples\sample.wav, can you handle it?
Heck NO!
Ok, so, SampleLoader002.dll, can you handle this file?
YEAH!

Now I just need to figure out the dynamics of things. I read somewhere in the JUCE forum that I can't just create a structure in the dynamic library and pass a pointer to it and let the host manage it, is this really right? Can someone shine a light on this?

Thanks again for listening and for any help/advice/tips.

Cheers, WilliamK

WilliamK · Post by **WilliamK** » Sat Dec 07, 2013 11:29 pm

PS: I'm very tired, so the idea above is not a complete thing, and may be totally stupid, so bear with me while I try to understand how I will handle this out...

WilliamK · Post by **WilliamK** » Fri Dec 13, 2013 4:15 pm

Still a bit stuck on the idea, will try to develop this better next week or maybe just NEXT YEAR!

aciddose · Post by **aciddose** » Sat Dec 14, 2013 2:23 am

WilliamK wrote:I read somewhere in the JUCE forum that I can't just create a structure in the dynamic library and pass a pointer to it and let the host manage it, is this really right? Can someone shine a light on this?

They must have meant something else. You can't allocate or free the memory associated with the object, so you need object = allocate() and free(object) functions, but this is exactly how almost every interface works. If it were true that it wasn't possible how would VST work?

Wusik 4000 Module SDK Docs Ready