DSP Robotics Support

RJHollins wrote:Question? With this concept, are we looking at maybe the possibility of 2 separate apps [say a VST], being able to communicate/share memory locations with the concept that is being explored here ?

I ask this as a mere mortal

I know this 'concept' as been discussed in the past ... even having a 'server/client' routine that was posted. I was just wondering if this 'memin workaround' has that type of possibility. That would be a very useful ability.

trying to learn from youse guys !

Certainly not... When you start an application the operation system reserves a space on RAM which the plugin will be free to use. It numbers the bytes of the memory. the process accesses the data in ram by calling the bytes by their number (which in case of 32bit windows is a 32bit integer). Your variables (their names) and arrays (their pointer names) are nothing more then just a visual replacement for the address integer (surely it is easier to identify a variable when it has name "counter" rather than "156464864"). One app usually can't access memory of another app. I do not know how passing values between apps/apps apps/plugins work.


I've just checked - opened two instances of flowstone with this schematic loaded. Both generated separate pointers and when I copied pointer form one to another it outputted nonsence... That is because for the second app, there was different data saved at that memory address.

not to deflect topic ...

oh well ... was hoping/wondering if there was a 'reserved' area of memory that could be shared in realtime between apps. [would be a useful technique].

Thanks for testing and confirming, and the details you provided. Educational.

I have came up with something that would solve the crashing problems to some degree. If the received address is nonexistent (zero) then the module would output an address, that is known to be readable without crashes. Only such address I know about is sine

so maybe


Now the pointer either points to the memory block or, if memory block is not created yet, it points to sine table. Does that make sense? or it would be more reliable to add "bypass if pointer address is zero" protection to every custom component that uses the mem?

I think sine is better. Usually sine is used by default, and other shape - if you change it. Instead of empty wavetables, you multiply output with 0 anyway (to avoid DC and other stuff).

KG_is_back wrote:if memory block is not created yet, it points to sine table. Does that make sense? or it would be more reliable to add "bypass if pointer address is zero" protection to every custom component that uses the mem?

i think bypass would be more logic, but it depends for what you use it, if it is used for wavetables maybe sine would be more logic but if its used for other stuff it would make no sense..

Here.... this should be as stable as possible (having a bypass everywhere possible). Working alternative memin and memarrayin, with working wave read and wave array read primitive copies.
Should behave exactly the same as the stock ones (the code is 95% identical)
Only one bug I can't solve - the mem to pointers module doesn't react to disconnection of the mem connector. Stock wave read stops playing if you disconnect it - this one doesn't until you trigger the mem connector. That causes crashes if you disconnect the mem connector and change the wave in the memory (the reader doesn't know the mem had changed and keeps reading the stuff at that position = crash). This problem should not occur in exported plugin/app (unless you use multiplexers for mem connectors).

thx KG,

as small part of mine i packed all the green stuff in the 'wavearray to pointers' module in a single ruby methode.

Nubeat7 wrote:thx KG,as small part of mine i packed all the green stuff in the 'wavearray to pointers' module in a single ruby methode.

Now that's one for a toolbox... Now I'm working on a wavetable oscillator (similar to stock one) and wavetable-array oscillator (Finally something unimplemented).

KG_is_back wrote:Now that's one for a toolbox... Now I'm working on a wavetable oscillator (similar to stock one) and wavetable-array oscillator (Finally something unimplemented).

Wow thats cool, make sure you post the results, it would be very interesting to see what you come up with!

Here a wavetable osc. With the Wave array it is a little more complicated... The wave array set primitive seems kinda buggy.