DSP Robotics Support

Hello!

I've been lurking here for about a month now, avidly devouring all the info that you guys have kindly shared with your examples, explanations and debates. There is a wealth of info here and at the SM site that has been monumentally useful in getting to grips with FS. Your generosity in sharing ideas is a credit to you all and much appreciated. I've been tempted to post with questions before, but have always found some useful pointers on the forum, but now I'm really stumped as to how to proceed with my project, so could do with some insights.

My project;
I built a simple MIDI / NRPN interface for one of my samplers (korg esx). Each incoming hit triggers exactly the same sample on the machine, but with a different start point. simple and very effective, plays live great, massively exploits the functionality of the machine.

The problem;
Although the plugin plays live without problems, when i try to record to the machine's internal sequncer, results are haphazard. Notes are allways recorded in the right place, but the NRPN data was often on the next step of the sequencer. I figured that because of the sequencer's low resolution (1/16), note and NRPN data were being seperated. I thought that by using a piano roller or adding a sequencer to my plugin I could get the input accurate enough to record correctly on the machine, but noticed EVEN MORE CONSISTENT FAIL. Every incidence of NRPN / CC data was on the step after it should have been.

A moment of clarity;
I realised that the problem wasn't accuracy it was rather that the sampler's sequencer records note and NRPN data differently. Note start point is quantised to the closest step start position, but cc data is recorded at the value it was at the start of each step. considering that the midi clock triggers the plugin, the CC data is never going to be right on the money and will always get shifted to the next step. to test this, i setup a midi loop in ableton and FL, triggering my plugin and.....turned off grid and shuffled the whole selection a nudge to the left. PERFECT results.

This leaves me with a big conundrum that kind of decides whether it is worth continuing development and if so how.
I want to make my plugin (or standalone) transmit data from just behind the midi clock, not exactly on it, but have no idea how to do this.

I have tried using the delay compensation primitive on the vst version of my interface, but this doesn't do the job, it delays the playing of everything except my interface, but still send clock and NRPN at the same sync

I think now that the only way forward now a standalone interface, where the clock and sequencer are slightly off sync (the clock very slightly behind the sequencer tick). Any suggestions as to how to do this would be greatly appreciated.

A present
I said in the title that there was a present and indeed I'd hate to introduce myself without anything to offer, so....here is an abomination that I made, it's based on the on the fly pattern switching that i used to use with FXpansion's Guru or now with midi clips in ableton. It is a ham fisted amalgamation of; my crappy clock / ticker, myco's tabbed GUI and the arp sequencer from the example synth. It is far from perfect, most of the schematics used are a bit of a mess as I'm still very much finding my way, but maybe someone will find the idea useful (although it's probably been done much better already), anyways, here it is.
use the 3 buttons to flick between which sequence is playing and sent to the outs.
The switcher also gives an idea of how the clock and the sequencer interact in my plugin too.
edit; oooooops, seems that my schematic is so bloated that i can't attach it (the enormous background image probably doesnt help!)
so here's a dl linky
https://www.dropbox.com/sh/m8egok231qkgio0/jj4RdrrdOR
thanks in advance for any pointers

Welcome to the forum. primate.

Tricky problem you have there. There's a possibility that the VST host might be part of the problem - in many cases, if the host discovers notes and CC/NRPN data that share a timestamp, the data gets re-ordered so that the notes are sent first. It's kind of redundant most of the time these days, because we mostly use VST plugins that react to data very fast - it was put there because hardware MIDI is pretty slow, and you generally don't want CC data to "choke" the interface and throw off the note timing. I may be possible to turn that off in some hosts - but in practice, it's not good to rely on changing obscure host settings to fix a problem like that.

Two things I would look into that may help you get the results you want...

1) It might be as simple as changing the priority of events within your sequencer schematic (the little 'tick marks' on the green links determine which links get priority). If your sequencer is reading the 'note event'' track, and then reading the 'NRPN data' track, the data will get sent out in that order too. By processing the data sets in the other order, you might be able to ensure that CC data is always sent first. If that works, you probably don't need the latency compensation.
This MIDI Analyser may help you with the timing analysis - it gives a detailed scrolling list of MIDI event in order of event time (it's very handy in a host when exported as a VST plugin too).

2) If that doesn't work, then you may be able to use a modification of the delay compensation method.
- Use a short delay compensation amount so that you are able to send data in advance.
- For only the note events, delay each event within the plugin by exactly the same amount - so that they are effectively moved back again to the original time. Delaying MIDI events is very simple using a short chunk of Ruby code...

Note that Ruby timing is only precise if your plugin has some audio streams running, so that it can sync to the sample clock. You can usually do that easily by just having a stereo pair of audio inputs connected straight through to a pair of audio outputs (i.e. an "audio" section that is a simple bypass with no processing.)

wow, Thanks a million. What a simple solution, I've already got the standalone version running perfectly.

I just put the simple midi delay module at the end of the midi clock / start / stop route before the midi out, using (15/BPM)/X (where X is a number between 1 and 100, inputted from a knob) so that i could try different fractions of a step length and keep the delay proportional to bpm. Seems that only a very minor adjustment was needed, with the sweet spot for correct recording being 1/20 of a step, a barely audible offset, but enough to do the job. I then added a toggle switch to use or bypass the delay for recording mode and live mode (not that there is much of a difference).

The vst version is a bit more complicated. I tried doing various things with offsetting notes / NRPN to no avail, as even with delay compensation, midi clock and midi data are always sent simultaneously as long as the DAW is in master sync mode, the only solution I can see here is to turn off master sync output in the DAW and let the vst output the start / stop and clock messages itself when playing is detected. Will try it out when I have a moment.

Thanks enormously, that tiny bit of code was all that I needed. I really need to get to grips with ruby, I think that my whole schematic could be reduced to a ruby box with a load of input knobs and a midi out, but this is going to take a while, for now at least I have a working prototype / proof of concept.

Looks like it's time to stert studying all those nicely annotated ruby examples you put up!