L00P

I could need some help sending a midi clock from a m4l patch... I'm bypassing lives midi port with leigh hunts excellent external because of lives limitations...

I need this to happen in a bpatcher.. The thing is the metro doesn't listen to lives transport there anymore...

sync~ is able to listen to a metro right?

I need this to happen in a bpatcher.. The thing is the metro doesn't listen to lives transport there anymore...
sync~ is able to listen to a metro right?

sending-midi-clock-synced-to-lives-transport-in-bpatch

Are you aware that Live can send midi clock? Why not use it?

As i mentioned before my device talks directly to a midi port outside of live's midi system to be able to handle NRPN (live doesn't even pass them along, which is a shame! Besides, that means I can do sysex sometime, another thing live sadly is ignoring) So the only midi in port of my synth is occupied and can not be also adressed from live, every time I do this I need to restart OSX to make the external work again.

The workaround (and maybe the saver way) would be to send a clock from live to a IAC (midi bus on mac) and back to my device again... But that's not very elegant..

As i mentioned before my device talks directly to a midi port outside of live's midi system to be able to handle NRPN (live doesn't even pass them along, which is a shame! Besides, that means I can do sysex sometime, another thing live sadly is ignoring)  So the only midi in port of my synth is occupied and can not be also adressed from live, every time I do this I need to restart OSX to make the external work again.

The workaround (and maybe the saver way) would be to send a clock from live to a IAC (midi bus on mac) and back to my device again...  But that's not very elegant..

Using Live's midi clock is definitely the best solution to ensure accurate timing.

But routing the clock over IAC through an M4L device would certainly mess up the timing.

Instead I'd suggest using 'MidiPipe' to resolve the port conflict.

Using Live's midi clock is definitely the best solution to ensure accurate timing.
But routing the clock over IAC through an M4L device would certainly mess up the timing.
Instead I'd suggest using 'MidiPipe' to resolve the port conflict.


ok thanks, didn't know MidiPipe. But isn't that also a midi bus? Do you have such bad experience with IAC? I always thought it was very stable and accurate, read in lots of cases about solutions/workarounds with IAC.

But routing it through M4L will most likely introduce timing problems. Just try it out..

No, IAC itself works perfectly for me.
But routing it through M4L will most likely introduce timing problems. Just try it out..


I just discovered something wierd: When I send a midi clock from live over the same port as my device both work as long as the transport is on... transport gating the port.. haha

I just discovered something wierd: When I send a midi clock from live over the same port as my device both work as long as the transport is on...  transport gating the port..  haha


Is there anything mentioned in the lh_midi documentation about occupying the port?

Maybe you could clarify this with an email to the author.

Is there anything mentioned in the lh_midi documentation about occupying the port?
Maybe you could clarify this with an email to the author.


Handling NRPN does work over Lives port natively!!!! The problem was the interface on my TI messed things up... Did further testing and when I'm using the port on the Motu Ultralite, it works perfectly. This is good news but I feel stupid... (actually less now)

So I'll use the lh external for SysEx only sometime...

Handling NRPN does work over Lives port natively!!!!   The problem was the interface on my TI messed things up...   Did further testing and when I'm using the port on the Motu Ultralite, it works perfectly.  This is good news but I feel stupid...  (actually less now)

So I'll use the lh external for SysEx only sometime...


sending midi clock synced to lives transport, in bpatch