MIDI sync

so I realized I am using 5.0.5, and I'm trying this again.

Since I had that thing where my ER1 would only advance 1 16th note, for every 20 [t 248] messages max would send, I tried using the [uzi] object and got it to work where if I send 6 bangs for every 16th note in max, then it's perfectly synced up...
so I suppose it's fixed... but I still have questions...

does this sound weird to anyone?
Is this what I should have been doing all along?
Is this a bug in max? Is it a bug in the ER1?
Is there a more efficient/elegant way of doing this?

I would appreciate any answers to any questions, suggestions for better ways of doing this. I attached a patch showing how I got it to work.

Thanks!
Mike

PS. slightly OT... why is there an "rtout" object that shows up in the list when I'm typing in "rtin"... but if you try and use it, it's not an object?

Michael schrieb:
> And I had tried just triggering [t 248] from a [metro] and that gave
> me another weird polyrhythm, again with the drum machine speeding up
> and slowing down as I changed the tempo in max, but still not in
> sync...

Check your settings, you want scheduler in overdrive and in audio
interrupt be checked, and no bang objects connected to tick metros.

You should also post patches for what you tried...

> I am just about to give up...

Just never give up...

I would try to let transport be the master and sync the drum machine,
and a request to C74 that transport should definitely support Midi as a
clock source. (Seems obvious, but seems also not been implemented yet
unless I am overlooking something...)

--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Thanks Stefan

I wouldn't really ever give up... but on occasion, I feel like it :)

The patch you posted still didn't sync it up right... again, as I increased the tempo in max, my drum machine did speed up, but they still weren't the same tempi. Did you get a chance to check out my reply to myself? I found a way to get it to work using uzi and sending "248" 6 times per 16th note, but that seems like an odd way to do it... and it left me with a few questions as to why that would work.

I appreciate your help, thanks!

Mike

Michael schrieb:
> Did you get a chance to check out my reply to myself?

No, I don't have syncable Midi gear...

> I found a way to get it to work using uzi and sending "248" 6 times
> per 16th note, but that seems like an odd way to do it... and it left
> me with a few questions as to why that would work.

Maybe your drummachine is a little Diva and only wants it that way...?
One have to serve Divas or they stop singing...

Stefan

--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Max 5 as Master, other way around forget it, though it still works better than a masto Logic.

This is a quick extract from a patch, it works pretty well with a korg Er-1, IO vector size should be 128 samps, and I strongly reccomend Overdrive On and Audio Interrupt too On (depending on how many other timing objects you are running).
In this case there is always a (MIDI) signal going out, but the MIDI gear will start and stop according to the 250, 252 messages. And will ensure that it stays in sync.
I often get shifts in sync which appear to be multiples of the sig vec size, you can easily put a remedy on that with the midioffset feature of sync.
With this configuration I keep in sync Live and MIDI gear from Max.

The Er is not really a diva, and the syncing problems happen with much gear, not to mention syncing other computers in the MIDI canonical way. But as italo culture says, there is always a way!

Its easy to patch an automatic start and stop with a Transport, though the previous suggestions of a MIDI syncable Transport are for sure the most appealing...
You can try and sync phasor (lock it) with a transport, but it gives whacky results and I always get sync~ out of sync like this (do not know why, guess it still needs improvements):
It works on paper, but as soon as the patch gets complex its starts to give problems, do not know why though.

Quote: mike@mikesperone.com wrote on Sat, 08 November 2008 23:14
----------------------------------------------------
> Since I had that thing where my ER1 would only advance 1 16th note, for every 20 [t 248] messages max would send, I tried using the [uzi] object and got it to work where if I send 6 bangs for every 16th note in max, then it's perfectly synced up...
> so I suppose it's fixed... but I still have questions...

midi clock is supposed to be 96 tick messages per bar. one problem with your current patch is the use of uzi to send 6 tick messages per 1/16, which does produce 96 tick messages per bar, but because of uzi it clumps 6 messages together every 1/16th.

i dont think that will be very good for midi timing because, generally, it doesnt handle lots of messages at once (altho this is hardware dependent...).

take a look at the patch below and see if that works better, altho i second the use of overdrive and other dsp settings as mentioned in previous replies.

i cant guarantee this will work as i have nothing to test with at the moment, but i do own an er-1 and can test later...

good luck,

justin

I see this question asked so frequently, and often with a wide variety of replies, I would think there should be a dedicated tutorial on the subject or some ready made patches in the cycling share library.

There are patches in the library as part of the sync~ object but they do seem a little unhelpful and vague. There should be a single tutorial on setting up MidiClock, MTC and MMC as both Master and Slave including the various system runtime messages. Also included in the tutorial should be a subsection on working with PQN.

thanks

Ken

We're still working on expanding the clocking options for the global transport.

In the meantime , you might also try

thanks all so much!

I didn't know about the 96 ticks per bar. These solutions are much nicer than mine. Thanks

Mike Sperone