Are my Ruby codes correct?

[nix]

Since I have been so successful at crashing my DAW with Ruby,
I would like to post 2 examples that I need to be 'proof read'.
A MIDI ticker->

MIDItimer_test.fsm

(25.19 KiB) Downloaded 932 times

MIDI timer.png (37.6 KiB) Viewed 20275 times

& a note on/off switch->

MIDI_OI_test.fsm

(8.16 KiB) Downloaded 904 times

If you'd like to tell me if these codes should be bug-free,
or what is wrong I would appreciate it.
Cheers, Nick

[nix]

MIDI_OI.png (17.78 KiB) Viewed 20274 times

little edit-
I see mucked up the init state of @sample_rate by leaving out the _ in the init.

[MyCo]

In the midi timer @tick is alway zero, so you could remove everything related to it. I don't get what the rest of the schematic does. You generate a Midi event, but don't use it at all... weird.

The Midi-OI(?) code looks way to complicated for what it does... could be done much simpler, like this:

Code: Select all

def event(i,v)
   output(Midi.new(v ? 144 : 128, 1, 60, 127))
end


[nix]

Thanks for chopping them down MyCo.
The idea with the MIDI tick is ->
1.It's function is outputting a green tick with the soundest possible timing.
2.It uses the soundcard's clock, the Ruby MIDI syncs to it.
The timing has errors as it goes to green, but they are minimal.
It's usable
3. You can render this in a DAW, as the MIDI will be opened by the DAW.
If you use green triggers, generally they don't render.

I will try the fixes you suggest, much thanks!

[trogluddite]

Hi nix,
I don't think it's your Ruby code as such that is making problems.
I think it's more likely that the feedback loop of the timer is unstable.
You essentially have a loop something like...

Ruby -> MIDI -> Green -> Ruby -> etc.

As Ruby and Green have completely different timing systems, and are probably on different CPU threads too, it's possible that the "circle of conversions" is what is causing the instability of the plugin - some sort of race condition going on that leads to triggers or Ruby events crashing into each other.

The kind of timer you want could be made much more simply by adapting the "Custom Ticker" from the toolbox - substitute your sample rate maths for the "step" input box, and then just use the green trigger that it puts out directly. The actual timing "loop" is then totally inside the Ruby primitive, so should be more accurate - the only change between different "clocks" would be at the green trigger output, with no green triggers going right around the loop and back into Ruby.

Using MIDI doesn't affect the timing, it's almost just an extension of Ruby in FS. The only requirement for sample accuracy is that you have some audio running somewhere - and once inside a VST export, you may not even need that, because all host<>plugin communication has to happen at that rate anyway (I'll be testing this soon with the PPQ thingy I'm working on).

[nix]

hmm,
when I think of this method I have used now,
I think it may accumulate significant errors after a few minutes.
Gotta test. It sounds well solid at like 300bpm,
but now concerned about rounding errors.
There is an advantage to generating the timing tick with MIDI imo.
Firstly it is less prone to discontinuities when doing graphical things,
and then like I say, it renders. Ruby ticks may render actually,
I've never tested, but certainly a tick25 or 100 will not function when doing a render.
Thanks for the thoughts and having a look at my schems.
It was this feedback timer causing the crash, I was generating 200hz to do mono to float.
I must have had some mistake with using an after load to turn it on.
I will certainly adapt the custom ticker, but perhaps I will keep using MIDI.

[trogluddite]

Ruby ticks may render actually,

Should be able to tell you for sure later today - next test of my PPQ sync thingy is to see if a pure MIDI seq' (i.e. no stream in schematic) will send to another VSTi with accuracy - if that works, then an off-line render will be the next test.
Fingers crossed!

Firstly it is less prone to discontinuities when doing graphical things,

Not noticed this - do you have an example that shows the problem?

[billv]

The kind of timer you want could be made much more simply by adapting the "Custom Ticker" from the toolbox - substitute your sample rate maths for the "step" input box, and then just use the green trigger that it puts out directly.

Trogs right here Nix. That custom ticker fix i posted, viewtopic.php?f=2&t=1254#p4195, generates VST Midi 100%. I had issues using the arp for the tick, so i tried that and it's spot on.
Use my Wave Seq upload to try it. Feed the modified custom ticker into the wave, and the beat float into the ticker.

[nix]

It's cool we're all working on this at the same time together.
The 3-pronged attack.
I checked your arp use again Bill,
I will come back to you after I have chopped the arp code down,
atm it seems overly complex for a tick firer.
I know our timing has come on in leaps and bounds though,
after this initial period we will have neat modules I'm sure.
Thanks for your help and continued effort.
So I modded the custom ticker to send a MIDI note on/off instead of a tick.
I will pm you an example showing the audio discontinuities caused by other operations,
if the little MIDI mod isn't done Trogs. I confirmed it again.
But, {cry} it's equally crashy in Orion.
Here is the new MIDI timer->

MIDItimer_test_mkII.fsm

(11.2 KiB) Downloaded 960 times

MIDI timerMKII.png (37.83 KiB) Viewed 20216 times

Does this code look alright also?
I'm pretty certain this is the single operation that is causing the crashes.
There is one instance of it in each schematic.
edit- Yay--Ruby ticks render, so I don't need to use MIDI, fingers crossed the MIDI stuff is the problem.
Trogs, the audio glitches generated by doing other stuff are only in flowstone, you can actually stop these by doing the midi thing and using a trigger thread,
this is not neccessary, the final build is glitch free in host. So just a little update.
It's so nice we can render ticks now.
Now I'll see if taking out the MIDI conversion stops my crashing.
edit2- It didn't, i dunno what's wrong. Also, the Ruby ticks do stutter when using GUI in host. MIDI is neccessary I think at this point again.
Now I'll delete things again to stop the crashing-starting with Ruby
edit3-It's not an incompatability between FS,Orion & Ruby per se. Example synth works fine with multiple instances. It's something I'm doing here.

[billv]

Here is the new MIDI timer->

Hope to test it soon. looks good.

atm it seems overly complex for a tick firer

I know, but it's not a tick firer, the tick is just drawn from it.
Like I said, i'm using the Modded Custom ticker for the tick now and it's brilliant.
I have this one locked at VST time so the clock,matrix,tickers and stuff are not affected by
X11 tempo changes.I've kept the other tick on a switch, so if the user wants the regular X11
Chaos, it's there. I did replace every timer with the Arp Timer, but will have to go back
and replace them all with the Modded custom ticker.
Replacing all the "green windows tickers", is proving a little tricky.
I created one with the same behaviour(that runs all the time) and replaced the windows ticker
in each of the 4 Big Mods, and got CPU spikes to 25%. So that was a failure. Will try again.
But the possibilities here are endless. Heaps of new new ideas for the X11.
Looking forward to finishing the timing platform, so I can start working.

after this initial period we will have neat modules I'm sure

Maybe we should create a thread called "Accurate Timers/Clocks and Sync", we we can post
them all in one place.