DSP Robotics Support

He he,
Looks a bit like my 'FS' version of Soopa Loopa at the moment!

tester wrote:Are you sure you wish to end up like this?

trogluddite wrote:Looks a bit like my 'FS' version of Soopa Loopa at the moment!

Always comforting to find your not alone....
Sounds bad at my end, but it's alright.
Stripping the Seq module back and starting again.
It was based on SM design...not built for the accuracy of Ruby.
Wave Seq/Arp Seq and stuff like that are all OK, just poorly implemented in the X11.
All these things removed will be re-developed again to suit X11 and FS.
It's taken me a few months to work the timing thing out, more confident now and excited about
finally being able to put this Seq Module together properly.

Looking forward to it - X11 is such a humdinger of a design, and the Ruby clock is the last piece of the jigsaw that it was crying out for. Take your time and give it all the TLC it deserves!

Yeh, the plan is now to quickly remove everything that's creates an error and upload.
At the moment it's got Scale Seq and 4 Note( they are always perfect) and they suffice for
standalone use, with host mode for VST working.
It's actually looking pretty good, leaner, less confusing.
When done with the fix, I can re-assess things and start a major re-build.

Looking more closely at the timing relationship between Arp and Ticker....
really interesting how they are working together, generating a slightly different tick to each
other, and still getting the end result.

Biggest issue for the X11 down the line is the graphics thing.
Its handling the "stress" test pretty well( moving plug-in while recording) but if you hold it
for a really long time you can squeeze out an error or two.
I don't fully understand what is happening to all those green triggers when you hold the synth
and the graphics stuff locks up...? Do they just sit there and build up.....do they hit a wall
and start releasing backward triggers..?
Been playing around with ruby here.... not getting any results yet....... really hard.....
But Trog, you did mention when I first started that I'll love FS, because of the way it handles
graphics...and I know you've been working a lot in this area.
Later on I will open a help thread on this, so i can factor this graphics issue into the major re-build.
So be warned..will be knocking at your door again with a s**tload of questions...

billv wrote: Do they just sit there and build up....

That's pretty much right.
Triggers basically work on a "queue" system, and get held in a big stack, each waiting their turn to be actioned.
A totally new trigger just joins the back of the queue, but if a trigger makes "child" triggers (gets split and sent in different directions, for example), the "child" triggers stay with their "parent" at the front of the queue.

When the CPU is really being pushed, new triggers might be arriving faster than the old ones are being processed, so the queue starts to grow very rapidly. In theory, there could be a 'brick-wall' if FS is only allowed a limited amount of memory to store the queue - but I don't recall seeing any problems that could definitely be pinned to that cause; the data to hold the state of a trigger would most likely be very small.

Drawing graphics complicates things further because they are drawn by 'Windoze' GDI+ engine, using the main CPU. When you redraw some graphics, FS isn't usually working all that hard - it's just sending some function calls to GDI+. But, FS has little control over how GDI+ uses CPU and memory resources, so we are at the mercy of the Windoze dev's whether drawing the graphics will make audio glitches - the trick is to always redraw as little as possible so that GDI+ isn't being pushed too hard.

Ruby also still uses GDI+ for the graphics, so problems with drawing big screen areas at high frame rates will still be there - so my comment before about Ruby being "better" for graphics are more to do with the extra control over "events" - so that redraws that aren't really needed can be avoided, and redraw areas are kept as small as possible.
That CAN be done with 'green', but the fixed trigger behaviour of primitives, invisible "backwards triggers", and extra "spaghetti" for trigger blockers etc. just makes it more difficult to optimise IMHO.
But of course that is only true once we have worked out all the best ways to use Ruby effectively!

trogluddite wrote:Triggers basically work on a "queue" system

Thanks for the insight trog.......got a great tip from Myco on the Trigger thread as well.
Should keep me going for a while when the time comes.
Cheers.

X11 UPDATED TO 2.02

Major re-build time.....
X11 has been stripped down to just the 4 Note seq and Host/User option.

*Wave Seq removed
*Draw Seq removed
*Scale Seq removed
*Wave Mod removed
+Fishtank removed
*Tick Signal to the 4 Mods adjusted

I also placed a few restrictions.......
*Use of "Random all tempo's" and "Random all Triggers" not possible while running.

X11 Updated to 2.03

* Tempo bugix.( one wire not connected in 2.02 update... )

X11 Updated to 2.04

X11 is now VST Plug-in only.
* Seq removed.
* Host tempo fix.

Ruby re-build going ok....maybe 6 months......
..so looks like 'a year to build"...and 'a year to fix'.......
I think it's a good thing....X11 was always a rough idea....just waiting to be re-developed.
Cost =...about 4 albums of crap that hardly no-one listens to anyway...

billv wrote:X11 Updated to 2.04
Cost =...about 4 albums of crap that hardly no-one listens to anyway...

Now you get the point. Not that I think your albums are crap (I don't know what they are, I admit - did not listened them yet); rather my viewpoint of project oriented programming. You have learned a lot of tricks, made a lot of templates, now it's time to use them. Maybe make something simple and attractive (combination of pleasant using and pleasant sounding), like otomata, to make the time you spent on it - worth it?