Using dll primitive as files encryptor

[kortezzzz]

Hi,

As we all know, using FS for building a sampler, in not the best idea, because your hard worked WAV files are completely bare. They can be easily copied by anyone and your project goes down the drain. So here is a little idea that came to my mind: I believe that mostly all of us know "Spectrosonics" plug-ins: Trilian, Stylus RMX and so on.

I know that they used to encrypt their sound libraries in dll files for long time. Well, it eventually has been cracked, but took a lot of time and man hours. AFAIK, FS may even call external dll files (we all saw trogs example),
so why can't we just seed the dll primitive inside our sampler and let it call a dll file that contains our samples, just like spectrosonics did, and stream them into the multisamples module directly from the dll primitive's output?...

I have no idea if it possible at all, as my coding skills are nil, but maybe one of the gurus here can answer?

[Exo]

Hey the main problem is the fact that the dll component doesn't work with the poly section. So streaming audio to the correct voice is currently not possible.

I do have plans to get the dll component working for poly it is not a simple task but I think it can be done. This of course would open up the possibility of disk streaming as well as many other things.

Malc is adding a few minor things(for something else) in the next update which I have asked for which should make the dll component in the poly section possible.

[kortezzzz]

Thanks exo. This is great news! The poly section support may get 2 birds in one shot. Both disk straming and file encrypting! Looks like the road to a new sampler is kinda wide open

[Nubeat7]

the only way i see would be to to encrypt your wave files, decrypt it inside your schematic and use the floatarray to mem prim together with the wave set array prim (r&d) to get them into the mem, the problem i see would be long loading times...

about the dll primitive, it would be groundbreaking to open the dll primitives for streams too (poly, mono, mono4) , or do you talking about just the mem or mem array connectors?

[Exo]

the only way i see would be to to encrypt your wave files, decrypt it inside your schematic and use the floatarray to mem prim together with the wave set array prim (r&d) to get them into the mem, the problem i see would be long loading times...

about the dll primitive, it would be groundbreaking to open the dll primitives for streams too (poly, mono, mono4) , or do you talking about just the mem or mem array connectors?

I'm talking about having voices pass through the dll primitive, it would require recording each voice to a buffer (Mem) I would then pass the address of the Mem into the dll component and extract each voice from the Mem. (The next release has a Mem to address primitive and also memin for code and ASM but shhh don't tell anybody )

[trogluddite]

If we could get some kind of "dll->mem" going that would be excellent news. By passing pointers out of a DLL, and some shenanigans with Ruby frames, it can sort of be done already. But, as DWB has pointed out in the past, the fact that green/Ruby/Audio are all on different threads makes it an open invitation for all sorts of nasty invalid pointer problems (i.e. instant crashes!!).

The dll's that I've been working on for the inter-process communication stuff may provide a different part of Sample/Rompler solution though...
They use a kind of Windows object called a "Mapped File" - and one of the main uses for these objects is to take a file that is too big to load all at once, and assign small chunks to local memory for very fast access (the process sharing is just a nice bonus feature!), with the current 'chunk' being very easy to move around the file. So they fit the bill for audio streaming very nicely.
Plus, they allow easy access from multiple instances, and automatically take care of a lot of the messy file and memory management that would otherwise be required. So they make the C++ design process much. much easier than it would be otherwise.
I'll definitely be experimenting with that feature once I have the data sharing stuff done. I'm just re-factoring at the moment to put the MappedFile stuff into it's own little library of functions - I'll post the source files up once its properly tested if anyone fancies a tinker.

[kortezzzz]

The dll's that I've been working on for the inter-process communication stuff may provide a different part of Sample/Rompler solution though...
They use a kind of Windows object called a "Mapped File" - and one of the main uses for these objects is to take a file that is too big to load all at once, and assign small chunks to local memory for very fast access (the process sharing is just a nice bonus feature!), with the current 'chunk' being very easy to move around the file. So they fit the bill for audio streaming very nicely.
Plus, they allow easy access from multiple instances, and automatically take care of a lot of the messy file and memory management that would otherwise be required. So they make the C++ design process much. much easier than it would be otherwise.

Sounds great, man. If I understand correctly, its a little bit like sf2 format? anyway, if it gonna work, I believe any "special encoding" won't be needed, as the format itself can not be adopted on the fly easily like the wav format (?), unless there is some converter (like "extreme sample converter") that does it. Keep in mind that any new method of disk streaming or else should solve both performance and security issues, or we can say goodbye nicely to the commercial sampler project dream.

[Nubeat7]

I'm talking about having voices pass through the dll primitive, it would require recording each voice to a buffer (Mem) I would then pass the address of the Mem into the dll component and extract each voice from the Mem. (The next release has a Mem to address primitive and also memin for code and ASM but shhh don't tell anybody )

i`ll be quiet like a grave

[Tronic]

I'm talking about having voices pass through the dll primitive, it would require recording each voice to a buffer (Mem) I would then pass the address of the Mem into the dll component and extract each voice from the Mem. (The next release has a Mem to address primitive and also memin for code and ASM but shhh don't tell anybody )

I hope also that implements the function call [eax]
so I can call a function from dll directly with your address,
and use the dll as plugin or mini-sdk.

[trogluddite]

Sounds great, man. If I understand correctly, its a little bit like sf2 format?

That would be the tricky bit - but also the advantage.

Tricky - because you have to encode/decode the file yourself in the dll code.
Advantage - because you have to encode/decode the file yourself in the dll code!

When you use a Mapped File, you can do it with any kind of file - the DLL accesses it as raw binary bytes. The 'sharing' feature of MappedFiles can also be turned off by making them 'Anonymous' so that another process isn't able to hook into them.

This way, you're totally free to create your own file format, and encode the audio data within it any way you like - your 'patches' would still be separate files, but only your own custom DLL would be able to read them. As DLLs can now be embedded inside a FlowStone module, the source code for your decoder isn't there at all - and even the compiled code is buried inside the much larger exported VST DLL file, so you'd have to find it first.

I'm only just beginning creating DLLs, so I have absolutely no idea how secure this really is, and it will depend a lot on how clever the encoding is, and how much secrecy you can keep when building the plugin. Most likely there would also be a trade-off between the security of encoding and the CPU load.
And, of course, none of this helps with the security of your licenses - if someone hacks your registration code validation, your whole plugin becomes warez, and it won't matter what audio format you use then!

But it's a lot more secure than FS could ever do before...