Timing

[billv]

how many nights have i dreamed of that

I couldn't imagine the collective hours that a lot of us have racked up trying to get it right.
And that's hands on testing, not just dreaming about it. can be a nasty job. test after test.....
And so now the "Holy Grail" of Accurate timing is gone. Ruby deserves it.
We tried for years in SM and failed.
Good part is that although the "timing issue is dead", it's definatly not buried.
There's lots of ways to stuff it up!!!!
I'm struggling now with Seq 2, which is a Wave Seq set up. I'm creating the notes in green,
then feeding into ruby to generate the midi. Not 100%, it drifts, so now I have to re-design it
untill I get it right. That's the big difference now-is that We don't have to settle for something
that isn't 100%. We can just keep going untill we get some of that "precise timing" that's
talked about in the User Guide.

[trogluddite]

Yes, that's the awkward bit. Converting from Green->Ruby / Ruby->Green messes up the timing, so there is more schematic to re-write than I first thought!

[billv]

Converting from Green->Ruby

Your "No backward trigger from Ruby" revelation has got me in a mess too Trog .
To use my Wave Seq, I need Ruby to automaticly read the @note.
Having to push it in has put me back into the green, I knew that would be trouble.

Code: Select all

def init
@note
end
def event i,v,t

    on = Midi.new 144,1,@note,12
    off = Midi.new 128,1,@note,12
    output 0,on
    output 0,off,t +0.25
    output 1,on
    output 1,off,t +0.25

Note:
What's the deal with this Mono to Frame thing?
This "precise sync" statement is a bit of a turn-on.
Can it be used for a PPQ set up. ???

ScreenShot108.png (36.2 KiB) Viewed 25238 times

For me also looks like a alternate way to spit out data from my Seq or Mods, and bypass a lot of green.

[trogluddite]

Hi Billy,
The notes trigger situation may be a matter of taking control of the trigger flow - this works a little differently in Ruby compared to what we're used to, but is actually very flexible once you get used to it.

Let me know if this is correct...
I am guessing that you have an incoming note value coming from part of your schematic - but you don't want the note to actually play until it receives a trigger from some other part of the schematic that handles the timing?
With the Ruby in your post, what is happening is that the note gets sent when the @note value changes, which fires the MIDI at the wrong time, and possibly with the wrong value - but if you block the trigger, it won't get sent at all!!

By adding a little code to the "event" section, it is possible to separate "update note value" and "send the note" into two completely separate events.
Here's a little example of how you would do that - hopefully the comments in the code will make it clear what is happening....

Trigger Testing.fsm

(1.79 KiB) Downloaded 1353 times

PPQ
Yes, I think you're on the right track. A frame is a collection of samples that is exactly one ASIO buffer in size, and totally in sync with the VST host. It's weird at first because we are so used to the SM "one sample at a time" way of doing things - but in reality, the host always sends data in buffer-size "chunks". SM has been hiding this from us for a long time!

Now, finding the beat starts should be quite simple - grab a 'frame' of the PPQ signal, and scan the data until you find that point where the ramp resets. ASIO buffers are so small, I think we can safely assume that there would never be more than one per frame!!
You could possibly also look for crossing other values in the ramp (e.g. 0.5 = half beat) for smaller timing divisions.

If the frame arrives at time "t", you should be able to say that the MIDI event needs sending at some time "t + offset", where offset represents how far into the buffer the crossing happened.

But hang on, time "t + offset" is some time in the future - surely it will then get sent too late?
This is the bit I've been experimenting with, and I think I need to go back to the drawing board because it may be simpler than I first thought. The host knows what the ASIO buffer size is, so my guess is that it would use 'latency compensation' to send the PPQ one frame in advance.
But that's only a guess, and my experiments ground to a halt when I got distracted by other things!!

The other slight trouble is that running a Ruby routine for every single incoming frame will use quite a bit of CPU power, because Ruby is nothing like as efficient as DSP code or assembly - so there are a few other little problems to solve...
1) Making the Ruby code totally, utterly as optimised as possible. For example, if the first and last PPQ values of the frame were, say, 0.69 and 0.71, there's no point scanning the whole frame because we're nowhere near the crossing point. (unless you're weird like me and want to test for quintuplet beats!).
2) There needs to be a 'Master Clock' so we only need one of those greedy Ruby timing routines!
3) Some way to distribute the clock around the schematic that doesn't need any "green" at all, so that we don't mess up our lovely new accurate timing. And for us folks with lots of old SM schematics, that means LOTS of modules to re-write!!
(NB - MIDI events are now integrated with Ruby, so the timing of MIDI links should be OK)

And thanks for bringing this stuff back to my attention.
Just writing out this description has really helped me to straighten out in my head exactly what we're trying to achieve, and break it down into little chunks that we can tackle one step at a time.
Off to a very noisy gig shortly, but if I'm not too hung-over tomorrow, I'll dig out my old experiments and see what improvements I can make.

[billv]

Thanks Trog, that gives me a lot to think about.
Will check out your trigger test tonight when I get home.
Last night i spent a few hours with the Mono to frame. Got some interesting results from it.
Seems it can be used as a "Ticker" extracting a green tick from blue.
( The Code in the Mono to frame module is the same from the User Guide.)

ScreenShot109.png (22.46 KiB) Viewed 25220 times

[trogluddite]

Hi Billy,
Had some very promising results with my re-coded PPQ sync. Made a new thread for it that you can find HERE.

[billv]

Here's a little example of how you would do that -Trigger Testing.fsm

Thanks mate. I see what you mean.
I didn't mention it, but i already had a S&H on the @note, with the tick pushing it in.

ScreenShot110.png (33.27 KiB) Viewed 25188 times

I started to test your method last night, but went off on several different tangents instead.
I'm still playing with the "silly" idea of bringing the Ruby accuracy down to green
Did about 6 versions.... this one is interesting, it's 100%, note is green. All I got to do,
like you said, is change it at the right time.

ScreenShot111.png (38.54 KiB) Viewed 25188 times

[nix]

Hey man,
u can see how I fared translating into green in ur pms.
I sent u the lastest DS

[billv]

Got it. Dreamtimer is a long way off man. tested in FL Studio.
Yeh, you got some work to do.
The module that has the "Start/Stop" buttons, has got to be re-done.
The way forward is ruby , most of that green has got to go.
Try this. It's a stripped down Arp Timer i built last night.

Arp Timer 2.fsm

(41.38 KiB) Downloaded 1380 times

[nix]

DreamSequence is actually seriousy broken.
Sorry man. Thanks for the timer example,
mainly I need to figure out how to read float arrays with Ruby I think.
I'll check the timer in the next couple of days.