Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

AUM: Option to send MIDI clock permanently (do not start and stop with transport)

@j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

Comments

  • If you have miRack Here's a bit of a kludge that might work but also might introduce instability ...

    The first Clocked module runs with AUM transport. The second one runs all the time. The switch takes care of which module is sent to output.

    • host sync module: set clock output to beat / 8
    • Clocked #1: tap mode+ until P8 is displayed. Double-tap module title to bring up the menu and set Momentary RUN input to on.
    • Clocked #2: mode should be at default, CV.

  • @catherder said:
    @j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
    The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
    There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
    I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

    Yeah, I know. There should be an option for that.
    One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.

  • @j_liljedahl said:

    @catherder said:
    @j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
    The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
    There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
    I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

    Yeah, I know. There should be an option for that.
    One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.

    The problem with the pre-roll is that you still have no clock before pressing start. I love jamming with my hardware synths, and in some configurations I need to be able to start and stop individual devices - including AUM transport. This is not possible with pre-roll. So I would highly appreciate hardware friendly MIDI clocking in AUM (ideally together with MIDI clock sync input).

  • @catherder said:

    @j_liljedahl said:

    @catherder said:
    @j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
    The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
    There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
    I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

    Yeah, I know. There should be an option for that.
    One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.

    The problem with the pre-roll is that you still have no clock before pressing start. I love jamming with my hardware synths, and in some configurations I need to be able to start and stop individual devices - including AUM transport. This is not possible with pre-roll. So I would highly appreciate hardware friendly MIDI clocking in AUM (ideally together with MIDI clock sync input).

    Just curious, even if clock is transmitted always, how do you start in beat sync?

  • edited January 2023

    @rs2000 said:

    @catherder said:

    @j_liljedahl said:

    @catherder said:
    @j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
    The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
    There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
    I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

    Yeah, I know. There should be an option for that.
    One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.

    The problem with the pre-roll is that you still have no clock before pressing start. I love jamming with my hardware synths, and in some configurations I need to be able to start and stop individual devices - including AUM transport. This is not possible with pre-roll. So I would highly appreciate hardware friendly MIDI clocking in AUM (ideally together with MIDI clock sync input).

    Just curious, even if clock is transmitted always, how do you start in beat sync?

    That's what the MIDI start/stop/pause/continue messages and additional information like the song position that can get transmitted via MIDI are made for. And in a jam, I sometimes do it by ear - specially when jamming with others.

  • @catherder said:

    @rs2000 said:

    @catherder said:

    @j_liljedahl said:

    @catherder said:
    @j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
    The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
    There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
    I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

    Yeah, I know. There should be an option for that.
    One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.

    The problem with the pre-roll is that you still have no clock before pressing start. I love jamming with my hardware synths, and in some configurations I need to be able to start and stop individual devices - including AUM transport. This is not possible with pre-roll. So I would highly appreciate hardware friendly MIDI clocking in AUM (ideally together with MIDI clock sync input).

    Just curious, even if clock is transmitted always, how do you start in beat sync?

    That's what the MIDI start/stop/pause/continue messages and additional information like the song position that can get transmitted via MIDI are made for. And in a jam, I sometimes do it by ear - specially when jamming with others.

    And that's the problem. Some hardware sequencers support it but hardly any app I know does support SPP so I guess that's more like a theoretical scenario.
    If you're able to start in time then by all means, go for it! :)

  • @rs2000 said:

    @catherder said:

    @rs2000 said:

    @catherder said:

    @j_liljedahl said:

    @catherder said:
    @j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
    The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
    There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
    I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

    Yeah, I know. There should be an option for that.
    One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.

    The problem with the pre-roll is that you still have no clock before pressing start. I love jamming with my hardware synths, and in some configurations I need to be able to start and stop individual devices - including AUM transport. This is not possible with pre-roll. So I would highly appreciate hardware friendly MIDI clocking in AUM (ideally together with MIDI clock sync input).

    Just curious, even if clock is transmitted always, how do you start in beat sync?

    That's what the MIDI start/stop/pause/continue messages and additional information like the song position that can get transmitted via MIDI are made for. And in a jam, I sometimes do it by ear - specially when jamming with others.

    And that's the problem. Some hardware sequencers support it but hardly any app I know does support SPP so I guess that's more like a theoretical scenario.
    If you're able to start in time then by all means, go for it! :)

    On hardware that supports it (Korg Volcas for example) I actually often use simple clock pulses instead of MIDI clock. That has the advantage that it is easy to start / stop and staying with the beat.

  • @catherder said:

    @rs2000 said:

    @catherder said:

    @rs2000 said:

    @catherder said:

    @j_liljedahl said:

    @catherder said:
    @j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
    The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
    There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
    I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

    Yeah, I know. There should be an option for that.
    One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.

    The problem with the pre-roll is that you still have no clock before pressing start. I love jamming with my hardware synths, and in some configurations I need to be able to start and stop individual devices - including AUM transport. This is not possible with pre-roll. So I would highly appreciate hardware friendly MIDI clocking in AUM (ideally together with MIDI clock sync input).

    Just curious, even if clock is transmitted always, how do you start in beat sync?

    That's what the MIDI start/stop/pause/continue messages and additional information like the song position that can get transmitted via MIDI are made for. And in a jam, I sometimes do it by ear - specially when jamming with others.

    And that's the problem. Some hardware sequencers support it but hardly any app I know does support SPP so I guess that's more like a theoretical scenario.
    If you're able to start in time then by all means, go for it! :)

    On hardware that supports it (Korg Volcas for example) I actually often use simple clock pulses instead of MIDI clock. That has the advantage that it is easy to start / stop and staying with the beat.

    Yeah, MIDI clock 24 pulses per quarter notes is not easy to manually trigger in sync with the beat! I'd even say impossible, unless it's a very very slow tempo :) AUM does send SPP, as per my interpretation of the standard it's sent on start if not starting from 0, and not sent for continue (un-pause). I don't see how SPP would allow you to start a device in sync with the beat, unless the receiving device keeps track of the current beat position while it's receiving clock?

  • @j_liljedahl said:

    @catherder said:

    @rs2000 said:

    @catherder said:

    @rs2000 said:

    @catherder said:

    @j_liljedahl said:

    @catherder said:
    @j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
    The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
    There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
    I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

    Yeah, I know. There should be an option for that.
    One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.

    The problem with the pre-roll is that you still have no clock before pressing start. I love jamming with my hardware synths, and in some configurations I need to be able to start and stop individual devices - including AUM transport. This is not possible with pre-roll. So I would highly appreciate hardware friendly MIDI clocking in AUM (ideally together with MIDI clock sync input).

    Just curious, even if clock is transmitted always, how do you start in beat sync?

    That's what the MIDI start/stop/pause/continue messages and additional information like the song position that can get transmitted via MIDI are made for. And in a jam, I sometimes do it by ear - specially when jamming with others.

    And that's the problem. Some hardware sequencers support it but hardly any app I know does support SPP so I guess that's more like a theoretical scenario.
    If you're able to start in time then by all means, go for it! :)

    On hardware that supports it (Korg Volcas for example) I actually often use simple clock pulses instead of MIDI clock. That has the advantage that it is easy to start / stop and staying with the beat.

    Yeah, MIDI clock 24 pulses per quarter notes is not easy to manually trigger in sync with the beat! I'd even say impossible, unless it's a very very slow tempo :) AUM does send SPP, as per my interpretation of the standard it's sent on start if not starting from 0, and not sent for continue (un-pause). I don't see how SPP would allow you to start a device in sync with the beat, unless the receiving device keeps track of the current beat position while it's receiving clock?

    There are many possible combinations of sending MIDI status messages and SPP.
    One way Roland have done it in their workstation sequencers is to sync to bar/pattern boundaries by sending a STOP, SPP, CONTINUE sequence (all between two clock ticks!) to make sure the receiver starts in time at the correct position.

  • @rs2000 said:

    @j_liljedahl said:

    @catherder said:

    @rs2000 said:

    @catherder said:

    @rs2000 said:

    @catherder said:

    @j_liljedahl said:

    @catherder said:
    @j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
    The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
    There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
    I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

    Yeah, I know. There should be an option for that.
    One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.

    The problem with the pre-roll is that you still have no clock before pressing start. I love jamming with my hardware synths, and in some configurations I need to be able to start and stop individual devices - including AUM transport. This is not possible with pre-roll. So I would highly appreciate hardware friendly MIDI clocking in AUM (ideally together with MIDI clock sync input).

    Just curious, even if clock is transmitted always, how do you start in beat sync?

    That's what the MIDI start/stop/pause/continue messages and additional information like the song position that can get transmitted via MIDI are made for. And in a jam, I sometimes do it by ear - specially when jamming with others.

    And that's the problem. Some hardware sequencers support it but hardly any app I know does support SPP so I guess that's more like a theoretical scenario.
    If you're able to start in time then by all means, go for it! :)

    On hardware that supports it (Korg Volcas for example) I actually often use simple clock pulses instead of MIDI clock. That has the advantage that it is easy to start / stop and staying with the beat.

    Yeah, MIDI clock 24 pulses per quarter notes is not easy to manually trigger in sync with the beat! I'd even say impossible, unless it's a very very slow tempo :) AUM does send SPP, as per my interpretation of the standard it's sent on start if not starting from 0, and not sent for continue (un-pause). I don't see how SPP would allow you to start a device in sync with the beat, unless the receiving device keeps track of the current beat position while it's receiving clock?

    There are many possible combinations of sending MIDI status messages and SPP.
    One way Roland have done it in their workstation sequencers is to sync to bar/pattern boundaries by sending a STOP, SPP, CONTINUE sequence (all between two clock ticks!) to make sure the receiver starts in time at the correct position.

    Interesting! I bet there are a few clock receiving devices/softwares that won't handle that well..

  • edited January 2023

    @j_liljedahl said:

    @rs2000 said:

    @j_liljedahl said:

    @catherder said:

    @rs2000 said:

    @catherder said:

    @rs2000 said:

    @catherder said:

    @j_liljedahl said:

    @catherder said:
    @j_liljedahl I would love to see an option that allows AUM to permanently send MIDI clock at the set tempo.
    The MIDI standard implemented clock as a means to synchronise the timers in (mainly hardware) synthesizers. The clock was never meant to be switched on and off with the transport. For this the system realtime start / stop / pause / continue messages are for.
    There is a good reason for this behaviour: The timers in the hardware need a (short) time to synchronise clock signal. If the clock is switched on and off, then there is the danger that the synth will run out of sync.
    I am aware of the downside of this: The fact that pressing transport start will not start immediately, but at the next clock. That's why it would be great to have this as an option.

    Yeah, I know. There should be an option for that.
    One easy solution to allow slaved devices to stabilize is to use one bar pre-roll.

    The problem with the pre-roll is that you still have no clock before pressing start. I love jamming with my hardware synths, and in some configurations I need to be able to start and stop individual devices - including AUM transport. This is not possible with pre-roll. So I would highly appreciate hardware friendly MIDI clocking in AUM (ideally together with MIDI clock sync input).

    Just curious, even if clock is transmitted always, how do you start in beat sync?

    That's what the MIDI start/stop/pause/continue messages and additional information like the song position that can get transmitted via MIDI are made for. And in a jam, I sometimes do it by ear - specially when jamming with others.

    And that's the problem. Some hardware sequencers support it but hardly any app I know does support SPP so I guess that's more like a theoretical scenario.
    If you're able to start in time then by all means, go for it! :)

    On hardware that supports it (Korg Volcas for example) I actually often use simple clock pulses instead of MIDI clock. That has the advantage that it is easy to start / stop and staying with the beat.

    Yeah, MIDI clock 24 pulses per quarter notes is not easy to manually trigger in sync with the beat! I'd even say impossible, unless it's a very very slow tempo :) AUM does send SPP, as per my interpretation of the standard it's sent on start if not starting from 0, and not sent for continue (un-pause). I don't see how SPP would allow you to start a device in sync with the beat, unless the receiving device keeps track of the current beat position while it's receiving clock?

    There are many possible combinations of sending MIDI status messages and SPP.
    One way Roland have done it in their workstation sequencers is to sync to bar/pattern boundaries by sending a STOP, SPP, CONTINUE sequence (all between two clock ticks!) to make sure the receiver starts in time at the correct position.

    Interesting! I bet there are a few clock receiving devices/softwares that won't handle that well..

    Definitely. Long time ago I worked at improving MIDI clock sync with the developer of Genome MIDI Sequencer and tested with many hardware sequencers and what was available on the Appstore and the only common denominator was clock and the status messages START, STOP and CONTINUE.
    Some apps today have at least nailed this very well (standouts being Audiobus, Loopy, BM3, Grooverider and now Drambo too) but most others work better with LINK - certainly because its spec doesn't have so many options and the LINK clock has high precision and priority.
    MIDI clock is just as stable when done correctly but it often isn't 😉

    The big advantage of LINK is that anyone can join a synced session anytime.

  • @rs2000 said:

    @j_liljedahl said:

    There are many possible combinations of sending MIDI status messages and SPP.
    One way Roland have done it in their workstation sequencers is to sync to bar/pattern boundaries by sending a STOP, SPP, CONTINUE sequence (all between two clock ticks!) to make sure the receiver starts in time at the correct position.

    Interesting! I bet there are a few clock receiving devices/softwares that won't handle that well..

    Definitely. Long time ago I worked at improving MIDI clock sync with the developer of Genome MIDI Sequencer and tested with many hardware sequencers and what was available on the Appstore and the only common denominator was clock and the status messages START, STOP and CONTINUE.
    Some apps today have at least nailed this very well (standouts being Audiobus, Loopy, BM3, Grooverider and now Drambo too) but most others work better with LINK - certainly because its spec doesn't have so many options and the LINK clock has high precision and priority.

    But why not just send some occasional (bar/pattern) SPP without STOP and CONTINUE? That would allow the receiver to easily keep track of the current beat position.

    Also, the Link-style individual stop/start in sync with the beat can totally be implemented in each receiver, even if the sender just sends a steady clock. Like this: a receiver of MIDI clock could have an option to ignore start messages, but still keep tracking the clock. The user could then press play on the receiver, and it could wait for a configured sync boundary and start playing in sync with the beat.

    MIDI clock is just as stable when done correctly but it often isn't 😉

    The big advantage of LINK is that anyone can join a synced session anytime.

    There are other advantages of Link. There is built-in latency compensation, it's easy to sync to the audio stream, it tells the exact position in beats instead of having to count ticks, etc.

  • @j_liljedahl said:

    @rs2000 said:

    @j_liljedahl said:

    There are many possible combinations of sending MIDI status messages and SPP.
    One way Roland have done it in their workstation sequencers is to sync to bar/pattern boundaries by sending a STOP, SPP, CONTINUE sequence (all between two clock ticks!) to make sure the receiver starts in time at the correct position.

    Interesting! I bet there are a few clock receiving devices/softwares that won't handle that well..

    Definitely. Long time ago I worked at improving MIDI clock sync with the developer of Genome MIDI Sequencer and tested with many hardware sequencers and what was available on the Appstore and the only common denominator was clock and the status messages START, STOP and CONTINUE.
    Some apps today have at least nailed this very well (standouts being Audiobus, Loopy, BM3, Grooverider and now Drambo too) but most others work better with LINK - certainly because its spec doesn't have so many options and the LINK clock has high precision and priority.

    But why not just send some occasional (bar/pattern) SPP without STOP and CONTINUE? That would allow the receiver to easily keep track of the current beat position.

    Because by definition in the MIDI standard, sending SPP will only have a "set cue point" effect without forcing the receiver to jump to that position. A STOP and CONTINUE sequence will make the receiver continue from the location given by the SPP, hence the STOP => SPP => CONTINUE sequence like described above.

    Also, the Link-style individual stop/start in sync with the beat can totally be implemented in each receiver, even if the sender just sends a steady clock. Like this: a receiver of MIDI clock could have an option to ignore start messages, but still keep tracking the clock. The user could then press play on the receiver, and it could wait for a configured sync boundary and start playing in sync with the beat.

    Hmmm. Just tracking the clock will only work if the clock stream starts with playback. Also, it's unlikely that a (flawed) receiver that might skip a clock tick here and there will reliably count clock pulses otherwise 😊
    What can be done without SPP though is a quick sequence of STOP and START at the end of a pattern. This would require equal pattern lengths in the sender and receiver though.

    MIDI clock is just as stable when done correctly but it often isn't 😉

    The big advantage of LINK is that anyone can join a synced session anytime.

    There are other advantages of Link. There is built-in latency compensation, it's easy to sync to the audio stream, it tells the exact position in beats instead of having to count ticks, etc.

    Yep, a good SDK is worth a lot (although I have to say that what @Michael has provided for MIDI clock sync is nothing short of fantastic as well 😉)

  • jason said:
    Regarding the MIDI specs, MIDI Clock and MIDI transport control and Song Position Pointer are completely separate concepts and not linked in any way. Also MTC, which is just another MIDI protocol. MIDI clock is MERELY for delivering pure information for tempo synchronisation. Its not stuck to start and stop commands. Many users and developers just do still mismatch this.

    That's not my interpretation. MIDI "System Real-time messages" include Clock (tick), Start, Stop, and Continue.

    Song Positition Pointer is mostly used in conjunction with this, but in theory all it does is cueing play position for the next time playback is started (regardless of how it's started).

    I agree MTC is a whole other protocol, used for syncing time code (for video/audio, not music/beat/tempo related).

    Then there's MMC, which is yet another protocol, used for remote control of transport (play, rewind, stop, pause, rec, etc).

  • @rs2000 said:

    @j_liljedahl said:
    Also, the Link-style individual stop/start in sync with the beat can totally be implemented in each receiver, even if the sender just sends a steady clock. Like this: a receiver of MIDI clock could have an option to ignore start messages, but still keep tracking the clock. The user could then press play on the receiver, and it could wait for a configured sync boundary and start playing in sync with the beat.

    Hmmm. Just tracking the clock will only work if the clock stream starts with playback. Also, it's unlikely that a (flawed) receiver that might skip a clock tick here and there will reliably count clock pulses otherwise 😊
    What can be done without SPP though is a quick sequence of STOP and START at the end of a pattern. This would require equal pattern lengths in the sender and receiver though.

    >
    It would track clock and start, continue, and possibly spp as well. If it can't keep track of time with this, then it's flawed in any case. But my point was that it could skip starting its own playback on reception of Start message, to get the Link-style "jump into playback on beat sync" behaviour.

  • @j_liljedahl said:

    @rs2000 said:

    @j_liljedahl said:
    Also, the Link-style individual stop/start in sync with the beat can totally be implemented in each receiver, even if the sender just sends a steady clock. Like this: a receiver of MIDI clock could have an option to ignore start messages, but still keep tracking the clock. The user could then press play on the receiver, and it could wait for a configured sync boundary and start playing in sync with the beat.

    Hmmm. Just tracking the clock will only work if the clock stream starts with playback. Also, it's unlikely that a (flawed) receiver that might skip a clock tick here and there will reliably count clock pulses otherwise 😊
    What can be done without SPP though is a quick sequence of STOP and START at the end of a pattern. This would require equal pattern lengths in the sender and receiver though.

    >
    It would track clock and start, continue, and possibly spp as well. If it can't keep track of time with this, then it's flawed in any case. But my point was that it could skip starting its own playback on reception of Start message, to get the Link-style "jump into playback on beat sync" behaviour.

    Oh yes, that's a good idea!

Sign In or Register to comment.