If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
Ruby problems again
13 posts
• Page 1 of 2 • 1, 2
Ruby problems again
More ruby problems here . Not just ruby components slow closing down but looks like there are another issuses. First automation on knob made with ruby in daw works only when plugin window is closed. Second - automation uses alot of CPU. Tried old version of plugin with green component knob and no probelm. Does anyone else have same problem?
-
TrojakEW - Posts: 111
- Joined: Sat Dec 25, 2010 10:12 am
- Location: Slovakia
Re: Ruby problems again
My guess might be: how often (Hz) automation triggers ruby window? I don't know if this is relevant to your issue, but as far I remember - if you try to set the ruby tick above 1kHz (less than 0.001s) - then it may hang. Maybe there is some interference between automation routine and gui usage by ruby (since there is only 1 interpreter).
I would try some redraw limiter, depending on where in the routing are your ruby modules.
I would try some redraw limiter, depending on where in the routing are your ruby modules.
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: Ruby problems again
why you think its ruby related? the automation data comes from preset parameter primitive!
are you using a redraw limiter to actualise your knob with incoming data..
never recognised some troubles if pluginwindow is opened or closed, again, it makes no difference if it is a ruby knob or not because the automationa data from your daw comes from the presetparameter primitive which doesnt care if your knob is ruby or not..?
maybe you can post your knob?
edit: thx tester you were faster with the redraw limiter..
are you using a redraw limiter to actualise your knob with incoming data..
never recognised some troubles if pluginwindow is opened or closed, again, it makes no difference if it is a ruby knob or not because the automationa data from your daw comes from the presetparameter primitive which doesnt care if your knob is ruby or not..?
maybe you can post your knob?
edit: thx tester you were faster with the redraw limiter..
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
Re: Ruby problems again
Redraw limiter is there. Same like in stock knob. I just test it and I completly replaced knob with stock ruby one and same thing. Automation works only with closed plugin window and it takes about 30% of CPU to automate just one event.
With green one automation works with window plugin open but CPU usage is high. Damn. It is about 10% without automation and about 29 with automation. But it is only replaced one knob within new version. With old plugin version without single ruby module it works like charm. So I'm sure it is ruby related problem.
With green one automation works with window plugin open but CPU usage is high. Damn. It is about 10% without automation and about 29 with automation. But it is only replaced one knob within new version. With old plugin version without single ruby module it works like charm. So I'm sure it is ruby related problem.
-
TrojakEW - Posts: 111
- Joined: Sat Dec 25, 2010 10:12 am
- Location: Slovakia
Re: Ruby problems again
Is there anything that gathers data differently in automation mode than in manual mode? For example, just came to my mind, that my undo/redo module may have a problem with automation, while it will work fine in normal editing. Reason - manual access provides blocking some triggers. Another thing to revisit - thanks!
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: Ruby problems again
hmm, did a few tests and the stock ruby knob needs 1,5% cpu more when automated while some rubyless knob, only could find some of tektoogs collections, needs nearly 3% morecpu when automated both with the normal redraw limiter in the stock presetparameter module for the knobs.. so here the stock ruby knob is faster then the green ones from tektoog
tested in renoise 3on my test laptop (win 7) which is really slow, no issues with opened plugin window..
maybe you really should get some faster computer?
maybe you can post one of your test schematics for comparing?
tested in renoise 3on my test laptop (win 7) which is really slow, no issues with opened plugin window..
maybe you really should get some faster computer?
maybe you can post one of your test schematics for comparing?
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
Re: Ruby problems again
tester wrote:Is there anything that gathers data differently in automation mode than in manual mode?
Well it just that during manual mode there is no request to refresh UI until you touch,adjust something. But question is how all theese ruby modules respond? Does really only automated module/knob refresh inside DAW? I'm just starting to lose confidence in ruby or rather say implementation of ruby inside flowstone.
Why not just send me the money.Nubeat7 wrote:maybe you really should get some faster computer?
Well I can't. This test schematic is actually schematic that four people work on for about one year. Why I still think it is ruby problem? Because s I said prototype plugin made with green stuff only gen only 1% CPU more during automation while ruby takes about 20%. I know I said thet replacing one ruby knob (automated one) doesn't help within new schematic but I still suspect that this is problem with many ruby modules inside single schematic. Not to mention the automation work for me with window open only with green knob.Till now I already done more work to reduce number of modules and I'm on 320 (935 original) and I thinking I reach the limit (it takes almost month to reduce that). Still some problems with more instances and now this one.Nubeat7 wrote:maybe you can post one of your test schematics for comparing?
You can just ask why not stick to green "prototyped" version of plugin then? Well thats impossible becasue many features are missing, different GUI design and so on. This new version takes one year to complete not prototyped version. Well I'm thinking about replacing all controls with green one but damn, this will be another long work. Well maybe there is another small positive thing about that that I can reduce number of ruby modules but I'm still worried what comes next .
If anyone know any plugin made with flowstone (not synthmaker) and it uses ruby modules for GUI, controls knobs sliders that work post a link I want to test it. Rather bigger synth not small with 10 controls.
-
TrojakEW - Posts: 111
- Joined: Sat Dec 25, 2010 10:12 am
- Location: Slovakia
Re: Ruby problems again
I would extract routines, one by one. Automation part, gui part, and so on, so that you can exchange parts with any else. And check them, one by one or in combinations. Thus - you should have no problem by posting something here.
You don't need to post your "little secrets". You may check the automation loop separately (connecting somewhere trigger counters) or in combination with any sort of gui; is this lag happens with any gui or specific ones? And play with removing things. There is no other way. Eliminate parts one by one, to find which setting causes the trouble.
Anyway. When using automation - automation affects gui in a way, that it moves knobs, updates editboxes, and so on (check for loops). When gui is closed - there is probably no update in yellow parts. If during automation - something hangs in gui (too high frequency of refreshing triggers) - then theoretically - it should block automation too, or at least - the ruby interpreter (the same for both).
I would add in crucial places some "Sample and Hold" prims, to block backward triggers. Trog recently made a tutorial that explains how things are recalculated in whole network if you don't block modules here and there. This might be the case too, and simple trigger counters would not show it.
Generally - you may need to revisit your philosophy at the end. And what comes next? Simpler and more effective solutions.
You don't need to post your "little secrets". You may check the automation loop separately (connecting somewhere trigger counters) or in combination with any sort of gui; is this lag happens with any gui or specific ones? And play with removing things. There is no other way. Eliminate parts one by one, to find which setting causes the trouble.
Anyway. When using automation - automation affects gui in a way, that it moves knobs, updates editboxes, and so on (check for loops). When gui is closed - there is probably no update in yellow parts. If during automation - something hangs in gui (too high frequency of refreshing triggers) - then theoretically - it should block automation too, or at least - the ruby interpreter (the same for both).
I would add in crucial places some "Sample and Hold" prims, to block backward triggers. Trog recently made a tutorial that explains how things are recalculated in whole network if you don't block modules here and there. This might be the case too, and simple trigger counters would not show it.
Generally - you may need to revisit your philosophy at the end. And what comes next? Simpler and more effective solutions.
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: Ruby problems again
well, i use only ruby for gui for all of my plugins and they all are working well, but i have to say that these projects are not mammut projects my biggest fx has about 23000 prims, 2500 modules, 28000 links, 3250 wireless, 300 ruby components
i`m using my rubyknob 3.0
from here:
viewtopic.php?f=3&t=641&start=50
and you can find some actual slider here:
viewtopic.php?f=3&t=1802
also buttons, selectors are done in ruby, just the backgraound is an image, it is a multifx plugin with 16 independent stepseq and 7 FX, the max cpu on my i5 laptop are nearly 12% when full modulated and automated
i`m using my rubyknob 3.0
from here:
viewtopic.php?f=3&t=641&start=50
and you can find some actual slider here:
viewtopic.php?f=3&t=1802
also buttons, selectors are done in ruby, just the backgraound is an image, it is a multifx plugin with 16 independent stepseq and 7 FX, the max cpu on my i5 laptop are nearly 12% when full modulated and automated
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
Re: Ruby problems again
tester:
Well thats what I do all the time. But what if you found something that you cant just change. Just like my previous post about number of ruby modules in schemaic. Empty or not less is better and none is the best. Why then inplement ruby if use cant really used it. Well you can but you have to be carefull not use it to much. What it is a demo or something? Don't mention that flowstone developers ignore my report that I send them - not a single word from them.
tester:
There are no secret. I just appreciate and respect work of my friend and I cant just show, share anything thats not my property. But plugins created will be free for anyone.
Thank for link but my knob is not much different than yours. Only diference if that I use only one ruby nodule in order to reduce number. Checked ruby code and also preset module and there is no real diference there, almost like thoose we use.
We also made fx plugin Amplio which works fine but it is small thing compared to this new synth, and even on my prehistoric computers it uses only 5% cpu. Can you post link to your dll? Or it is comrecial? If you can I liked to test it.
tester wrote:I would extract routines, one by one. Automation part, gui part, and so on, so that you can exchange parts with any else. And check them, one by one or in combinations.
Well thats what I do all the time. But what if you found something that you cant just change. Just like my previous post about number of ruby modules in schemaic. Empty or not less is better and none is the best. Why then inplement ruby if use cant really used it. Well you can but you have to be carefull not use it to much. What it is a demo or something? Don't mention that flowstone developers ignore my report that I send them - not a single word from them.
tester:
tester wrote:You don't need to post your "little secrets"..
There are no secret. I just appreciate and respect work of my friend and I cant just show, share anything thats not my property. But plugins created will be free for anyone.
tester wrote:i`m using my rubyknob 3.0
Thank for link but my knob is not much different than yours. Only diference if that I use only one ruby nodule in order to reduce number. Checked ruby code and also preset module and there is no real diference there, almost like thoose we use.
tester wrote: it is a multifx plugin with 16 independent stepseq and 7 FX
We also made fx plugin Amplio which works fine but it is small thing compared to this new synth, and even on my prehistoric computers it uses only 5% cpu. Can you post link to your dll? Or it is comrecial? If you can I liked to test it.
-
TrojakEW - Posts: 111
- Joined: Sat Dec 25, 2010 10:12 am
- Location: Slovakia
13 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 58 guests