DSP Robotics Support

'Concept'

- A file with a bitmap containing the knob is loaded, the bitmap is then streamed across the schematic into each individual module/knob.

- Why use this ratter than the regular ruby knob you wonder?

The problem with the ruby knob...is that Ruby tends to save inside its code assembler the memory of the png file...

for that reason, if you use a ruby animated knob lets say 100 times, it will load the same bitmap 100 times, that's an incredible ineficient way of making a plugin...You do NOT want that... because every time your plugin loads in a midi sequencer/DAW, you will be using 100 times more memory than the exact efficient way necessary to run
the plugin...

This is the correct way... this is logic

You load it only once...you use coding in ruby to rotate it (!)
in this case i made an hybrid between primitive modules and ruby, because the primitive draw
allow you to stream bitmaps.

I am not a ruby developer, so if you are and you know how to stream bitmaps in ruby...
please do tell, meanwhile this is a solution i was looking!


cheers

That has nothing to do with Ruby, but with the fact that the default knobs use a green bitmap loader purposely to store the image data.

tulamide wrote:That has nothing to do with Ruby, but with the fact that the default knobs use a green bitmap loader purposely to store the image data.

The default knob use a bitmap loader, that's correct...


But then what happens? when you give instructions in ruby to draw the image... the assembler will keep the image...
it will store it...

just try this, open a default knob... load an image, and then remove the loader...
you will notice, the image is still there in the knob... because its not dynamic, ruby is not reading the image from the green bitmap source, ruby uses it, to load it... but it keeps the image on the assembler in memory

in my prototype, if you remove the loader, the knob disapears... check it... if you remove the loader, they are gone
because the image is being streamed dynamically, unlike in ruby case...

This is why i had all this work, trying to figure out, a way to do this...

Right now, i am making some testing, im going to compare a plugin with more than 100 knobs using the regular default knob, and other with the method i am using...

interesting, following.

Inputs store their value (in this case an image), but again, that has nothing to do with Ruby. It's a standard Flowstone input.

Grab a default knob, remove the bitmap loader, drag an after load prim in to the schematic and connect it to the bitmap input. Bitmap gone.

For example, all of your knobs in your example still hold the original bitmap. Test it. Right under


paste this code


See, how it draws the original bitmap right under your new one? So if at all, your version will even be worse, as it saves a bitmap AND draws another one on top. Why you didn't notice it? Because the default knob you used doesn't have a strip. It is only one image of a knob without anything that isn't used as animation. So it's only like 1/40 or even less of the size of an animated strip. That's all.

tulamide wrote:Inputs store their value (in this case an image), but again, that has nothing to do with Ruby. It's a standard Flowstone input.

Grab a default knob, remove the bitmap loader, drag an after load prim in to the schematic and connect it to the bitmap input. Bitmap gone.

For example, all of your knobs in your example still hold the original bitmap. Test it. Right under

Code: Select all

# DRAWING (scroll down for interaction)

paste this code

Code: Select all

def draw v
  v.drawBitmap(@image, [0, 0])
end

See, how it draws the original bitmap right under your new one? So if at all, your version will even be worse, as it saves a bitmap AND draws another one on top. Why you didn't notice it? Because the default knob you used doesn't have a strip. It is only one image of a knob without anything that isn't used as animation. So it's only like 1/40 or even less of the size of an animated strip. That's all.

hmmm, Can you show me a an example how to do thast? j

My purpose here is to not let the plugin load unnecessary amounts of memory... so basically if i understood what you said correctly... your saying that if i use the after load trigger, it will reload the knob bitmap after the plugin is working... ok...

But how the hell i clean the plugin before export dll?

because i dont want the plugin to be exported with 100 knobs containing bitmaps data wasting memory...

have you made any tests with 100 knobs? which makes a bigger vst dll file? The ruby knobs or the old ones?

adamszabo wrote:have you made any tests with 100 knobs? which makes a bigger vst dll file? The ruby knobs or the old ones?

Hello adam, yes i did...

using the exact same image, i made 2 vst dummy with 80 knobs each, both with the same image loaded.

to not make an unfair comparison, i used in both as well only one loader for the image...
and that means, the first i did was to create knob, take out the loading unit, and place outside connected via wirless...
then 79 knobs were coppied....

the ruby default animated knob, using only ruby code, consumes 40 mb per instance, notice this is only a dummy...
there is no dsp code inside the module, its only to compare the eficiency of the memory usage considering the bitmaps and knob quantity....

80 knobs in ruby use 4928 components

and, my "hybrid" 80's knobs dummy, uses 9787 components... the double

so, in theory, if the "hybrid dummy" uses the double of the components, it should waste the double of the memory per instance right??

quite contrary... in my testing, each hybrid 80 knob dummy consumes per instance 26 mb... almost half of the mb used by the ruby knob...

So imagine... if we find a way of streaming a bitmap across the schematic, using ruby, combining that with another simple ruby assembler inside each knob only to the rotation stuff and save the knob data etc etc

this will be extremely efficient.. i am talking about very complex plugins (like your Viper per example) matching the memory efficiency of plugins like Dune 2 or Zebra, wich are incredibly complex, but still they only use 10/15 mb per instance...

So i ask again, if anyone in the forum knows how to stream bitmaps in ruby, please do share.. because this is very important for everyone.

The old synthmaker style can be somewhat lesser on memory if You share the one bitmap loader for many knobs. Just use the
module out links and link back from interaction and put the bitmap loader modules in the main schematic.

Did you even check his schematics? He loads one bitmap and sends them out wirelessly to all the knobs just like you said