Streamable knob prototype...

[wlangfor@uoguelph.ca]

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

Yes I figured it might be something like that, but then again I never Use ruby. Just the old primitives for knobs due to the sound quality hrm I guess.

Anyways, You might have some luck not using wireless connectors? I've noticed due to the bugs that the combination of multiplexers and selectors in tandem now use more memory than before. It may be a start to developing that connectivity You're hoping for. I think often it comes down to memory holes and caching happening or not happening (or unpredictability).

But the linked connections are pretty stable; Maybe a start (an afterthought)

[Ricciardo]

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

Yes I figured it might be something like that, but then again I never Use ruby. Just the old primitives for knobs due to the sound quality hrm I guess.

Anyways, You might have some luck not using wireless connectors? I've noticed due to the bugs that the combination of multiplexers and selectors in tandem now use more memory than before. It may be a start to developing that connectivity You're hoping for. I think often it comes down to memory holes and caching happening or not happening (or unpredictability).

But the linked connections are pretty stable; Maybe a start (an afterthought)

Using Old SM primitives only for making knobs is not efficient, they use around 500-600 components per knob, each...
it might not seem much, but when you have a complex plugin, you will end up with alot of unnecessary components that will make your plugin not only load slower, as also consume unnecessary memory.

This is why i made this hybrid knob, it uses the old SM draw module, but it also uses ruby...
its made of 120 components, ratter than 500-600...

Its fully dynamic, and it works just as any other knob, except its more efficient using memory.

[tulamide]

Just to be clear: Having one bitmap that serves as source for all the knobs that uses it is the right approach, but please stop making Ruby responsible for the issue. It has nothing to do with it. It is the Flowstone inputs that store the bitmaps.

And that was demanded by us users (not me, but still)! Prior to (I think) version 3.0.6, the bitmap inputs to Ruby did not store the bitmaps, and everyone was complaining about it. They wanted it to behave just like the bitmap prim itself, and so DSPR changed it to its actual behaviour.

Ruby works just the same with or without this Flowstone feature!

[wlangfor@uoguelph.ca]

Yeah, I agree about Ruby - It's great. I was meaning that due to the amount of customization I add to a knob; for instance:

- I like there to be a switch dependent on whether or not the knob is being turned which I use prolifically;
- I like the fact that the old version is very dependable

Using Ruby is ideal; I'm not a hater; But I have tested other styles of optimized knobs like Barak's which seemed start and stop.
There was a claim it was faster but it wasn't and I gave up trying for alternatives lol.

But anyways, to clarify; I just meant maybe it was the wireless connection that was the issue. Perhaps this person might try the standard link rather than wireless. I've noticed primitives have had strange behavior in versions later than 2 and I realize it was probably due to bugfixes.

Maybe I'd sometime want to make a ruby equivalent that did everything. I probably could. I especially like the mouse hover feature.
It'd be cool if the program were to time how long You were turning so as to toggle the label from a 3 decimal value to a 1 decimal value in combination with the knob title (Gain IN:1.2dB).

I just haven't seen that kind of flexibility yet. But maybe I'll try and do that. If this person gets streaming working maybe I can add that too. I'm working on a universal system for double click text input and touchscreen input values; Give it a look.
http://flowstone.co.uk/support/viewtopic.php?f=3&t=13634&sid=e25a2242140025f3ef9bf0f955b0a49d

When I'm done it I'll make a ruby equivalent. I used to program for a living it shouldn't be too hard.

I like Ruby, and thanks for trying to get this streaming working.

[Ricciardo]

Just to be clear: Having one bitmap that serves as source for all the knobs that uses it is the right approach, but please stop making Ruby responsible for the issue. It has nothing to do with it. It is the Flowstone inputs that store the bitmaps.

And that was demanded by us users (not me, but still)! Prior to (I think) version 3.0.6, the bitmap inputs to Ruby did not store the bitmaps, and everyone was complaining about it. They wanted it to behave just like the bitmap prim itself, and so DSPR changed it to its actual behaviour.

Ruby works just the same with or without this Flowstone feature!

Than that request is a huge mistake, it completely prevents plugins from being optimized, ruby functionality should be used to draw stuff and make calculations... not to store data, unless requested.

but maybe, there are some lines of code that can be used so ruby doesn't save the data?
i would like to know more about that...

Specially if there is a way to load directly from a folder into ruby dynamically, that would be dope...
if we could acess the images directly from a source outside the plugin using ruby.

I know there is a way to load bitmaps using plugin folder, but still, if ruby saves the bitmap data by default, its completely pointless to do that.

What we really need is flexibility, it would be better if there were commands to save or not the bitmap in ruby, depending on the what the user want.

[tulamide]

Than that request is a huge mistake, it completely prevents plugins from being optimized, ruby functionality should be used to draw stuff and make calculations... not to store data, unless requested.

but maybe, there are some lines of code that can be used so ruby doesn't save the data?
i would like to know more about that...

Specially if there is a way to load directly from a folder into ruby dynamically, that would be dope...
if we could acess the images directly from a source outside the plugin using ruby.

I know there is a way to load bitmaps using plugin folder, but still, if ruby saves the bitmap data by default, its completely pointless to do that.

What we really need is flexibility, it would be better if there were commands to save or not the bitmap in ruby, depending on the what the user want.

I give up. In your answer you once again do it. See the red text, pointing out the mistakes. You can't find a way to optimize things, if you don't understand that Ruby is not involved in any of it! Nothing is saved in Ruby, as you wrongly stated!! FLOWSTONE SAVES THE BITMAP DATA. Precisely, the Flowstone Editor. As soon as you export, nothing is saved by Flowstone anymore.