Track delay shift - possible?


#1

I’ve got a synth with appears to have a few ms of latency (or at least that’s how I’m hearing it), and I’d like to apply a negative delay shift to the track, after quantisation, to compensate. Is this possible on the Pyramid?


#2

Yes you can do it, but the problem is if you have notes that appear on the first beat, they will wrap around to the last beat, so won’t be heard on the first instance of play.


#3

No, wrong. This cant be done after quantize.


#4

Sure it can! Not after quantize midi fx but after consolidating the quantize it can.


#5

That was my point. It cant be done after quantize FX.
And the “fix” to offset notes early throws off first notes. This is surely not a solution to anyone anywhere.


#6

Well in some cases it can be ok, but often the way to deal with it can be to advance the timing of all the other tracks to compensate but this can be a huge undertaking if there are a lot of tracks :rofl:


#7

OK - thanks for confirming!


#8

Thats exactly why we need this!


#9

Haha :cross: :horse:


#10

Haha @darenager :trolleybus:


#11

Maybe we can call the veterinarian to revive it :slight_smile:


#12

:ambulance:


#13

Would be really nice to have an effect that is called track delay, that you can put last in the fx chain or even better, incorporate it in the instrument definition files! that way if some intruments have delay it would be corrected when pulling up the def. file and you dont have to think about it :slight_smile:

(added this in the feature req, becuse i think its important to play tiiight)


#14

Until that time, I’ve just decided to get rid of my Roland Boutiques. Spent far too much time trying to compensate for their sluggish response. Even 20ms of latency makes them unusable for me.


#15

You could get an ERM Multiclock. You can set up 4 independent clocks with +/- offsets to account for hardware latencies. Very handy if you need to clock to a DAW too. They ain’t cheap but I’m sure it would hold its value til you get your track delay wishes.


#16

@Cupachump what Boutiques do you have problems with? I know the first 3 have some midi latency but pretty sure the subsequent models don’t - although I have not checked. 20ms seems quite a lot, it would be audible from a keypress with a fast attack sound, are you sure it is that much?


#17

The Multiclock costs over €400 and it will do nothing to fix the issue of MIDI note latency. Its job is synchronising sequencers and drum machines. Only the sequencer sending the MIDI notes can apply a negative delay to them!


#18

I’ve got the JP08 and whilst it’s OK for pads and the like, for basses and rhythmic stuff the latency is clearly audible compared to my other synths. Doesn’t look like firmware updates are going to sort it out either.


#19

I just tested JP08, SH01a and TR08 midi note trigger latency 18, 11, 8ms respectively. To test I triggered them from my Octatrack recording into it and checked the offset, direct midi connection, I checked both USB audio and 3.5mm audio but the difference was negligible.

I have not tested any of my other synths but I think most will fall into that range, since I don’t really notice any discrepancies when using them in conjunction with the Boutiques. I think that jitter is more noticeable than lag, especially if the lag is consistent, which from my tests seems to be the case, also factor in midi delays when multiple messages on multiple channels are being sent.


#20

Yes @Panason you are very right. I’m confusing things. It doesn’t work like that at all. I use the multiclock to mitigate for latencies but driving other sequencer clocks on the other devices and doing my programming on them rather than in the Pyramid… which is not what the OP is interested in.

If the OP wanted to programme on one of his/her boutiques and use Pyramid for other modules then the Multiclock could be used to offset the clocks.

But i guess the problem is related to the boutiques receiving and processing note on/off etc late over MIDI rather than firing notes from its internal sequencer which one would assume likely to be tighter.

Sorry everyone.

jim