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 frustration
3 posts
• Page 1 of 1
Ruby frustration
Got to vent a bit..
The way Ruby timing works is veeery un-intuitive. Everything get's processed at the same time-slice, even though you trigger them to happen after each other. For example, if two ruby modules receive a trigger from the same trigger button they get processed at the "same time", hence making any parameter exchange between them useless. I've been building modular processing nodes (i can just pile them up x100) and this "feature" has been driving me nuts
There is of course workarounds.. involving time-delayd outputs etc.
If there is better ways to do this, let me know. Like writing stuff up as classes?
The way Ruby timing works is veeery un-intuitive. Everything get's processed at the same time-slice, even though you trigger them to happen after each other. For example, if two ruby modules receive a trigger from the same trigger button they get processed at the "same time", hence making any parameter exchange between them useless. I've been building modular processing nodes (i can just pile them up x100) and this "feature" has been driving me nuts
There is of course workarounds.. involving time-delayd outputs etc.
If there is better ways to do this, let me know. Like writing stuff up as classes?
- matti
- Posts: 55
- Joined: Fri Sep 24, 2010 12:06 pm
Re: Ruby frustration
matti wrote:..if two ruby modules receive a trigger from the same trigger button they get processed at the "same time"..
sure when you have on source, but there is a triggerordering in the same order you connected the the modules( what was connected first get served first)
there are several ways to take control over your triggers, but without schematic it is difficult to tell
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
Re: Ruby frustration
Yes, would be good to see the schematic.
Another potential problem is that "green" and "Ruby" are on different CPU threads - so when you convert between Green<->Ruby, the timing can't be guaranteed. Passing data between Ruby blocks will be more stable using the 'Ruby Value' (white V) connectors and links.
Another potential problem is that "green" and "Ruby" are on different CPU threads - so when you convert between Green<->Ruby, the timing can't be guaranteed. Passing data between Ruby blocks will be more stable using the 'Ruby Value' (white V) connectors and links.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
Don't stagnate, mutate to create!
-
trogluddite - Posts: 1730
- Joined: Fri Oct 22, 2010 12:46 am
- Location: Yorkshire, UK
3 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 68 guests