DSP Robotics Support

trogluddite wrote:

Exo wrote:Threads can be very useful to decrease load times.

Very interesting
I've never dared to use them for routine schematics - only "emergency use" for the MIDI trigger bugs of long ago! now that I'm messing with concurrency in C++, I am a little less scared, so I might have to have a play with this.

Yes try them wherever you use after load triggers. The schematic doesn't fully load until all the processing has finished that the after load has triggered. So if you are doing some heavy processing like creating multiple Wavetables then the benefits are obviously pretty big.

Father wrote: i don't think i can fall back to bitmap, no control over shapes and colors. I guess i have to choose between beauty and function eventually!

what i do here is, i capture a picture from my app as png - you can find 'capture' under 'view' in the menubar- then i cut it to the right size and load it as backgraound, just take care that you don't show the moving parts when doing the capture


sadly the capture function included in FS is not very good quality, some improvement here would be great..

i think i saw some schematic with built in bitmap generators which then can be used for knobs or buttons.., you can use the bitmapcreate primitive for it, but i never tested this methode

but i think its a good way to keep everything flexible and when finished capture it and use its bitmaps, if the drawing of the moving parts done simple and lightweight its a good way

Nubeat7 wrote:i think i saw some schematic with built in bitmap generators which then can be used for knobs or buttons.

You can find a module for "rendering" views in my old Trogz Toolz collection on the SM forum - seems to load OK in FS. It's the module called "View Cache" in the GUI section.
You put it between your MGUI and whatever view you want to draw. If the image needs to change, just send it a trigger and it rebuilds the bitmap - any other event calling a redraw will just draw the bitmap instead of the whole View.

I've used it a lot for "backgrounds" that are rarely updated - e.g. a sample wave display with a playback cursor running across it, or large panels of formatted text. It can make a big difference in situations like that.
It's also easy enough to add a 'Bitmap Save' to make exporting panel backgrounds easier - unlike the "Capture" menu item, it will only save the View plugged into the module, so the bitmap won't include all the animated controls that might be layered on top.

P.S) There's no Ruby equivalent for this, as Ruby can only draw bitmaps, it can't create or edit them in any way. (yet?!?!)

tulamide wrote:I am currently working on two graphics modules that will enable you to use both, beauty and function

Looking forward to it.

Exo wrote:Are you using any multi LFOs in your effect?

Yes, but having them or not isn't making any difference.

Nubeat7 wrote:what i do here is, i capture a picture from my app as png - you can find 'capture' under 'view' in the menubar- then i cut it to the right size and load it as backgraound

It seems like a good idea in most cases. But for example if you want the user be able to change the color of some knobs, then static bitmap isn't the answer.

trogluddite wrote:You can find a module for "rendering" views in my old Trogz Toolz collection on the SM forum - seems to load OK in FS.

That sounds really cool! Unfortunately i couldn't log in to SM forum to check it out.

Father wrote:That sounds really cool! Unfortunately i couldn't log in to SM forum to check it out.

I'll see about posting it over here when I'm back from work - I've been holding off because I wanted to "upgrade" the modules for FS. But that's going VERY slowly, so I'll just delete any that don't work in FS for now.

I just replaced my ruby codes with standard modules to draw the knobs, and there was noticeable improvement in loading time. about 25%

Father wrote:I just replaced my ruby codes with standard modules to draw the knobs, and there was noticeable improvement in loading time. about 25%

I found (in old SynthMaker before FlowStone/Ruby) that the fewer calculations & triggers you have to do to initialize, the faster loading time is. I was able to take out alot of unneeded primitives (esp in knobs) which helps in loading time. Also using Sample&Holds to help prevent re-calculations help.

There are a few other mistakes, like permanently loading the WAV file inside the schematic, rather than loading externally.

infuzion wrote:I found (in old SynthMaker before FlowStone/Ruby) that the fewer calculations & triggers you have to do to initialize, the faster loading time is. I was able to take out alot of unneeded primitives (esp in knobs) which helps in loading time. Also using Sample&Holds to help prevent re-calculations help

That's exactly right. Me too, had to strip down most calculations to improve loading time.
I figured loading time is all about green and yellow! However I'm surprised by how much time they're taking to initialize. 3 or 4 secs is a long time for a FX plugin to load up, even for relatively complex GUI.
I wonder if there is a way to measure or compare the loading time for different modules.

After putting some hours into this, i came to some conclusions:
1: Do not use "system fonts" module in your schematics!
2: Ruby bitmap is slower on load.
3: Drawing lots of shapes is not recommended. Use bitmap if possible.

1) ?
3) ?

Well, a matter of taste.