Loopy Pro: Create music, your way.

What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.

Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.

Download on the App Store

Loopy Pro is your all-in-one musical toolkit. Try it for free today.

The Great BPM Link War

AudioGusAudioGus
edited September 2017 in General App Discussion

When an app that supports Link is added to the current session it either aquires the current BPM or imposes it's own. Some do, some don't. Some is, some ain't, so it begs the question...

The Great BPM Link War
  1. Should an app change or aquire the current BPM?43 votes
    1. Change it!
        0.00%
    2. Aquire it!
      53.49%
    3. How about asking?
      46.51%
«1

Comments

  • AndyPlanktonAndyPlankton

    I like the apps which ask politely what I want :)

  • AudioGusAudioGus

    @AndyPlankton said:
    I like the apps which ask politely what I want :)

    Oohh, hadn't though of that... ok new poll options!

  • ExAsperis99ExAsperis99

    And lo, did the grammarians lament. Or possibly laminate.

  • ExAsperis99ExAsperis99

    Apologies for the snark.

    I actually would like to know what the chain of command is in a Link setup. AUM seems to overtake everything, resetting all of my beats to a chipper 120 bpm. So how does it work? The first app opened governs the tempo? Or are some apps more equal than others?

  • AudioGusAudioGus

    @ExAsperis99 said:
    And lo, did the grammarians lament. Or possibly laminate.

    Wrapped in heated plastic no?

  • ciancian

    .> @AudioGus said:

    When an app that supports Link is added to the current session it either aquires the current BPM or imposes it's own. Some do, some don't. Some is, some ain't, so it begs the question...

    A link app should never impose it's own BPM unless it's the first app to join the session. So that's developers failing to read the specification properly.

  • [Deleted User][Deleted User]

    How about the option of some apps with Link like Patterning which enable you to turn off Link to enable either MIDI clock sync or IAA sync which may be preferable depending upon the particular setup you're running at the time. You can have a situation where an app such as AUM can host Patterning and you want Patterning to respond to AUM's transport controls so you'd set Patterning to IAA host sync. You may have another situation where you want Patterning to respond to MIDI clock sent out by MIDI hardware or an iOS sequencer that only sends out MIDI clock. You could have a situation where you start playing some other apps first and want Patterning to come in on the beat so Link would be preferred. The poll would be more useful if it reflected these options.

  • brambosbrambos

    @cian said:
    .> @AudioGus said:

    When an app that supports Link is added to the current session it either aquires the current BPM or imposes it's own. Some do, some don't. Some is, some ain't, so it begs the question...

    A link app should never impose it's own BPM unless it's the first app to join the session. So that's developers failing to read the specification properly.

    ^ what he said.

  • AudioGusAudioGus

    @InfoCheck said:
    How about the option of some apps with Link like Patterning which enable you to turn off Link to enable either MIDI clock sync or IAA sync which may be preferable depending upon the particular setup you're running at the time. You can have a situation where an app such as AUM can host Patterning and you want Patterning to respond to AUM's transport controls so you'd set Patterning to IAA host sync. You may have another situation where you want Patterning to respond to MIDI clock sent out by MIDI hardware or an iOS sequencer that only sends out MIDI clock. You could have a situation where you start playing some other apps first and want Patterning to come in on the beat so Link would be preferred. The poll would be more useful if it reflected these options.

    I think for now I am ignoring midi clock in this poll and sticking to just Link. Gotta start somewhere and I just want to keep the Link only side simple.

  • lukesleepwalkerlukesleepwalker

    @cian said:
    .> @AudioGus said:

    When an app that supports Link is added to the current session it either aquires the current BPM or imposes it's own. Some do, some don't. Some is, some ain't, so it begs the question...

    A link app should never impose it's own BPM unless it's the first app to join the session. So that's developers failing to read the specification properly.

    Bingo. I like the way AUM or Loopy ask, though. Sometimes you want that new app to take charge, right?

  • AudioGusAudioGus

    @cian said:
    .> @AudioGus said:

    When an app that supports Link is added to the current session it either aquires the current BPM or imposes it's own. Some do, some don't. Some is, some ain't, so it begs the question...

    A link app should never impose it's own BPM unless it's the first app to join the session. So that's developers failing to read the specification properly.

    Ahh! There be guidelines then... hmmm ok, maybe some polite email or direct message initiative is in order.

  • nrgbnrgb

    Docs are here if people are interested: ableton.github.io/linkkit/

  • [Deleted User][Deleted User]

    @brambos said:

    @cian said:
    .> @AudioGus said:

    When an app that supports Link is added to the current session it either aquires the current BPM or imposes it's own. Some do, some don't. Some is, some ain't, so it begs the question...

    A link app should never impose it's own BPM unless it's the first app to join the session. So that's developers failing to read the specification properly.

    ^ what he said.

    It may still be desirable to have the option to specify if an app with Link enabled is able to be set so that it can change BPM in response to another Link app's change in BPM or for it to remain. For this to be effective you'd need to be able to set this option for all of the apps in the setup and be able to save the setup for easy recall. Some desirable options for Link would be to all start in sync in response to transport controls or not, start on the beat, and to toggle global BPM change or not.

  • encenc

    Should default to the Bpm set on the first app opened.

  • [Deleted User][Deleted User]
    edited September 2017

    @AudioGus said:

    @InfoCheck said:
    How about the option of some apps with Link like Patterning which enable you to turn off Link to enable either MIDI clock sync or IAA sync which may be preferable depending upon the particular setup you're running at the time. You can have a situation where an app such as AUM can host Patterning and you want Patterning to respond to AUM's transport controls so you'd set Patterning to IAA host sync. You may have another situation where you want Patterning to respond to MIDI clock sent out by MIDI hardware or an iOS sequencer that only sends out MIDI clock. You could have a situation where you start playing some other apps first and want Patterning to come in on the beat so Link would be preferred. The poll would be more useful if it reflected these options.

    I think for now I am ignoring midi clock in this poll and sticking to just Link. Gotta start somewhere and I just want to keep the Link only side simple.

    When you ignore MIDI clock sync, you're ignoring hybrid setups and in general the underlying issue with sync on iOS which is you have three different protocols that users need to navigate to be able to use all of their gear unless they limit themselves to Link only protocols. I prefer to be able to drive my music based upon what I want to do rather than some manufacturer's technical framework. It basically boils down to are the machines serving our needs or are we serving theirs?

    If the language the machines speak is too difficult to figure out, this can be a barrier to doing things the way we want. The whole point of the creation of the MIDI standard was to enable users to learn just one control protocol rather than having to learn each manufacturer's protocol and then figure out how to get all of those protocols in sync. I'd still prefer that app developers, operating systems, and hardware manufacturers all cooperate to make life easier for us so that sync becomes their problem to address rather than the musicians. Ideally musicians just need to know what they want to do. The less time spent delving into the underlying non-musical support structure the better.

  • DCJDCJ

    I never understood why the BPM on BM3 would change when I'm adding a synth to the program. I've often forgotten the original BPM and find myself tapping tempo frantically before I lose my mojo. :'( :'( :'(

    Should automatically take the tempo of the first or even the previous linked app.

  • lukesleepwalkerlukesleepwalker

    @DCJ said:
    I never understood why the BPM on BM3 would change when I'm adding a synth to the program. I've often forgotten the original BPM and find myself tapping tempo frantically before I lose my mojo. :'( :'( :'(

    Should automatically take the tempo of the first or even the previous linked app.

    That should never happen. Great example!

  • AudioGusAudioGus

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:
    How about the option of some apps with Link like Patterning which enable you to turn off Link to enable either MIDI clock sync or IAA sync which may be preferable depending upon the particular setup you're running at the time. You can have a situation where an app such as AUM can host Patterning and you want Patterning to respond to AUM's transport controls so you'd set Patterning to IAA host sync. You may have another situation where you want Patterning to respond to MIDI clock sent out by MIDI hardware or an iOS sequencer that only sends out MIDI clock. You could have a situation where you start playing some other apps first and want Patterning to come in on the beat so Link would be preferred. The poll would be more useful if it reflected these options.

    I think for now I am ignoring midi clock in this poll and sticking to just Link. Gotta start somewhere and I just want to keep the Link only side simple.

    When you ignore MIDI clock sync, you're ignoring hybrid setups and in general the underlying issue with sync on iOS which is you have three different protocols that users need to navigate to be able to use all of their gear unless they limit themselves to Link only protocols. I prefer to be able to drive my music based upon what I want to do rather than some manufacturer's technical framework. It basically boils down to are the machines serving our needs or are we serving theirs?

    If the language the machines speak is too difficult to figure out, this can be a barrier to doing things the way we want. The whole point of the creation of the MIDI standard was to enable users to learn just one control protocol rather than having to learn each manufacturer's protocol and then figure out how to get all of those protocols in sync. I'd still prefer that app developers, operating systems, and hardware manufacturers all cooperate to make life easier for us so that sync becomes their problem to address rather than the musicians. Ideally musicians just need to know what they want to do. The less time spent delving into the underlying non-musical support structure the better.

    Out of curiosity, what options would you have added to the poll to reflect your points?

  • AudioGusAudioGus

    @DCJ said:
    I never understood why the BPM on BM3 would change when I'm adding a synth to the program. I've often forgotten the original BPM and find myself tapping tempo frantically before I lose my mojo. :'( :'( :'(

    Should automatically take the tempo of the first or even the previous linked app.

    Hah! Exactly the scenario that led to this thread.

  • [Deleted User][Deleted User]
    edited September 2017

    @AudioGus said:

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:
    How about the option of some apps with Link like Patterning which enable you to turn off Link to enable either MIDI clock sync or IAA sync which may be preferable depending upon the particular setup you're running at the time. You can have a situation where an app such as AUM can host Patterning and you want Patterning to respond to AUM's transport controls so you'd set Patterning to IAA host sync. You may have another situation where you want Patterning to respond to MIDI clock sent out by MIDI hardware or an iOS sequencer that only sends out MIDI clock. You could have a situation where you start playing some other apps first and want Patterning to come in on the beat so Link would be preferred. The poll would be more useful if it reflected these options.

    I think for now I am ignoring midi clock in this poll and sticking to just Link. Gotta start somewhere and I just want to keep the Link only side simple.

    When you ignore MIDI clock sync, you're ignoring hybrid setups and in general the underlying issue with sync on iOS which is you have three different protocols that users need to navigate to be able to use all of their gear unless they limit themselves to Link only protocols. I prefer to be able to drive my music based upon what I want to do rather than some manufacturer's technical framework. It basically boils down to are the machines serving our needs or are we serving theirs?

    If the language the machines speak is too difficult to figure out, this can be a barrier to doing things the way we want. The whole point of the creation of the MIDI standard was to enable users to learn just one control protocol rather than having to learn each manufacturer's protocol and then figure out how to get all of those protocols in sync. I'd still prefer that app developers, operating systems, and hardware manufacturers all cooperate to make life easier for us so that sync becomes their problem to address rather than the musicians. Ideally musicians just need to know what they want to do. The less time spent delving into the underlying non-musical support structure the better.

    Out of curiosity, what options would you have added to the poll to reflect your points?

    I think for me it's difficult to address these issues with a poll like this unless you have an all of the above option with the following additional options:

    1. Ability to save Link preference setups per app/host app/preset
    2. Ability to incorporate non-Link sync protocols in a Link network setup.
    3. Option to have Link sync based on transport controls.
    4. Link/sync options would have most common use cases as default with more complex options requiring a deeper level of app navigation so that the needs of people who have more common setups can easily set things up to their liking and people who want more customized/complex setups will have those options available without burdening other users who will not need, use, or want them.
    5. Be able to use my apps and hardware how I want without needing to know anything about Link.

    I would choose option five even though it's fantasy material for the foreseeable future.

  • brambosbrambos

    @InfoCheck said:
    2. Ability to incorporate non-Link sync protocols in a Link network setup.

    This is actually 'not allowed' per the Link specs. Obviously Ableton can't block apps that don't follow this rule, but they make it pretty clear that apps should not mix multiple sync protocols simultaneously.

    1. Be able to use my apps and hardware how I want without needing to know anything about Link.

    Yeah.. that would be awesome, but I'm not sure how they could make it any easier than it is today. It's just a matter of "switch it on" and it works. As long as all apps follow the rules, that is.

  • AudioGusAudioGus

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:
    How about the option of some apps with Link like Patterning which enable you to turn off Link to enable either MIDI clock sync or IAA sync which may be preferable depending upon the particular setup you're running at the time. You can have a situation where an app such as AUM can host Patterning and you want Patterning to respond to AUM's transport controls so you'd set Patterning to IAA host sync. You may have another situation where you want Patterning to respond to MIDI clock sent out by MIDI hardware or an iOS sequencer that only sends out MIDI clock. You could have a situation where you start playing some other apps first and want Patterning to come in on the beat so Link would be preferred. The poll would be more useful if it reflected these options.

    I think for now I am ignoring midi clock in this poll and sticking to just Link. Gotta start somewhere and I just want to keep the Link only side simple.

    When you ignore MIDI clock sync, you're ignoring hybrid setups and in general the underlying issue with sync on iOS which is you have three different protocols that users need to navigate to be able to use all of their gear unless they limit themselves to Link only protocols. I prefer to be able to drive my music based upon what I want to do rather than some manufacturer's technical framework. It basically boils down to are the machines serving our needs or are we serving theirs?

    If the language the machines speak is too difficult to figure out, this can be a barrier to doing things the way we want. The whole point of the creation of the MIDI standard was to enable users to learn just one control protocol rather than having to learn each manufacturer's protocol and then figure out how to get all of those protocols in sync. I'd still prefer that app developers, operating systems, and hardware manufacturers all cooperate to make life easier for us so that sync becomes their problem to address rather than the musicians. Ideally musicians just need to know what they want to do. The less time spent delving into the underlying non-musical support structure the better.

    Out of curiosity, what options would you have added to the poll to reflect your points?

    I think for me it's difficult to address these issues with a poll like this unless you have an all of the above option with the following additional options:

    1. Ability to save Link preference setups per app/host app/preset
    2. Ability to incorporate non-Link sync protocols in a Link network setup.
    3. Option to have Link sync based on transport controls.
    4. Link/sync options would have most common use cases as default with more complex options requiring a deeper level of app navigation so that the needs of people who have more common setups can easily set things up to their liking and people who want more customized/complex setups will have those options available without burdening other users who will not need, use, or want them.
    5. Be able to use my apps and hardware how I want without needing to know anything about Link.

    I would choose option five even though it's fantasy material for the foreseeable future.

    I agree with number 5 and the way to get there is by breaking down all of the different issues regarding sync and connectivity into smaller issues and adressing them one at a time, which is exactly what the poll on this thread is doing. Not one thread or poll is going to get us there.

  • [Deleted User][Deleted User]
    edited September 2017

    @brambos said:

    @InfoCheck said:
    2. Ability to incorporate non-Link sync protocols in a Link network setup.

    This is actually 'not allowed' per the Link specs. Obviously Ableton can't block apps that don't follow this rule, but they make it pretty clear that apps should not mix multiple sync protocols simultaneously.

    1. Be able to use my apps and hardware how I want without needing to know anything about Link.

    Yeah.. that would be awesome, but I'm not sure how they could make it any easier than it is today. It's just a matter of "switch it on" and it works. As long as all apps follow the rules, that is.

    You've identified exactly why the life of a music app developer can be challenging because:
    1. Musicians have a wide variety of requirements.
    2. Requirements of some musicians conflict with those of other musicians.
    3. The economics of the App Store are more volume based rather than niche based with the value of apps set at a level to support development cost.
    4. Musicians can't adequately describe or perhaps know what their requirements are with sufficient detail to be the basis upon which to develop an app.
    5. Musicians can feel apps don't meet their needs and become backseat developers with little insight into the issues surrounding development which is reflected in the solutions they suggest.

    Given 1-5, I believe my best strategy is to focus on clarifying what I want to do, express it as clearly as I can without trying to be a developer, and leave it up to developers to figure out if it's possible or feasible to create an app to meet such a need. Be okay with whatever follows from there since I will not be developing an app and developers do not have magic wands.

    I do think Link, Audiobus 3, and AU are all protocols that are moving things forward in a direction I like and your apps incorporate these approaches which is greatly appreciated. In addition you frequently provide us insight into the challenges and practical limitations developers have to deal with which gives me a lot of food for thought.

  • brambosbrambos

    @InfoCheck said:
    Given 1-5, I believe my best strategy is to focus on clarifying what I want to do, express it as clearly as I can without trying to be a developer, and leave it up to developers to figure out if it's possible or feasible to create an app to meet such a need.

    Certainly the best strategy! There are so many different workflows on iOS that for us designers/devs it's much more important to understand 'why something is needed' than 'that something is needed' - so we can some up with a solution/compromise that aligns with as many different ways of working as possible. :)

  • [Deleted User][Deleted User]

    @AudioGus said:

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:
    How about the option of some apps with Link like Patterning which enable you to turn off Link to enable either MIDI clock sync or IAA sync which may be preferable depending upon the particular setup you're running at the time. You can have a situation where an app such as AUM can host Patterning and you want Patterning to respond to AUM's transport controls so you'd set Patterning to IAA host sync. You may have another situation where you want Patterning to respond to MIDI clock sent out by MIDI hardware or an iOS sequencer that only sends out MIDI clock. You could have a situation where you start playing some other apps first and want Patterning to come in on the beat so Link would be preferred. The poll would be more useful if it reflected these options.

    I think for now I am ignoring midi clock in this poll and sticking to just Link. Gotta start somewhere and I just want to keep the Link only side simple.

    When you ignore MIDI clock sync, you're ignoring hybrid setups and in general the underlying issue with sync on iOS which is you have three different protocols that users need to navigate to be able to use all of their gear unless they limit themselves to Link only protocols. I prefer to be able to drive my music based upon what I want to do rather than some manufacturer's technical framework. It basically boils down to are the machines serving our needs or are we serving theirs?

    If the language the machines speak is too difficult to figure out, this can be a barrier to doing things the way we want. The whole point of the creation of the MIDI standard was to enable users to learn just one control protocol rather than having to learn each manufacturer's protocol and then figure out how to get all of those protocols in sync. I'd still prefer that app developers, operating systems, and hardware manufacturers all cooperate to make life easier for us so that sync becomes their problem to address rather than the musicians. Ideally musicians just need to know what they want to do. The less time spent delving into the underlying non-musical support structure the better.

    Out of curiosity, what options would you have added to the poll to reflect your points?

    I think for me it's difficult to address these issues with a poll like this unless you have an all of the above option with the following additional options:

    1. Ability to save Link preference setups per app/host app/preset
    2. Ability to incorporate non-Link sync protocols in a Link network setup.
    3. Option to have Link sync based on transport controls.
    4. Link/sync options would have most common use cases as default with more complex options requiring a deeper level of app navigation so that the needs of people who have more common setups can easily set things up to their liking and people who want more customized/complex setups will have those options available without burdening other users who will not need, use, or want them.
    5. Be able to use my apps and hardware how I want without needing to know anything about Link.

    I would choose option five even though it's fantasy material for the foreseeable future.

    I agree with number 5 and the way to get there is by breaking down all of the different issues regarding sync and connectivity into smaller issues and adressing them one at a time, which is exactly what the poll on this thread is doing. Not one thread or poll is going to get us there.

    I think addressing specific protocol level issues one at a time to perfect different aspects of a music workflow is an approach a developer would use whereas for me, I'd prefer to explain what I want to do from a musical point of view and then have developers solve the problem for me if possible. I'm not a great musician and my ability to program is even worse so I wouldn't put too much stock in any of my development suggestions. For me, the utility of polls is dependent upon the degree to which developers find them useful.

  • [Deleted User][Deleted User]

    @brambos said:

    @InfoCheck said:
    Given 1-5, I believe my best strategy is to focus on clarifying what I want to do, express it as clearly as I can without trying to be a developer, and leave it up to developers to figure out if it's possible or feasible to create an app to meet such a need.

    Certainly the best strategy! There are so many different workflows on iOS that for us designers/devs it's much more important to understand 'why something is needed' than 'that something is needed' - so we can some up with a solution/compromise that aligns with as many different ways of working as possible. :)

    Perhaps you could come up with or direct us to some poll guideline suggestions or templates so we can improve the quality of our polls?

  • AudioGusAudioGus

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:
    How about the option of some apps with Link like Patterning which enable you to turn off Link to enable either MIDI clock sync or IAA sync which may be preferable depending upon the particular setup you're running at the time. You can have a situation where an app such as AUM can host Patterning and you want Patterning to respond to AUM's transport controls so you'd set Patterning to IAA host sync. You may have another situation where you want Patterning to respond to MIDI clock sent out by MIDI hardware or an iOS sequencer that only sends out MIDI clock. You could have a situation where you start playing some other apps first and want Patterning to come in on the beat so Link would be preferred. The poll would be more useful if it reflected these options.

    I think for now I am ignoring midi clock in this poll and sticking to just Link. Gotta start somewhere and I just want to keep the Link only side simple.

    When you ignore MIDI clock sync, you're ignoring hybrid setups and in general the underlying issue with sync on iOS which is you have three different protocols that users need to navigate to be able to use all of their gear unless they limit themselves to Link only protocols. I prefer to be able to drive my music based upon what I want to do rather than some manufacturer's technical framework. It basically boils down to are the machines serving our needs or are we serving theirs?

    If the language the machines speak is too difficult to figure out, this can be a barrier to doing things the way we want. The whole point of the creation of the MIDI standard was to enable users to learn just one control protocol rather than having to learn each manufacturer's protocol and then figure out how to get all of those protocols in sync. I'd still prefer that app developers, operating systems, and hardware manufacturers all cooperate to make life easier for us so that sync becomes their problem to address rather than the musicians. Ideally musicians just need to know what they want to do. The less time spent delving into the underlying non-musical support structure the better.

    Out of curiosity, what options would you have added to the poll to reflect your points?

    I think for me it's difficult to address these issues with a poll like this unless you have an all of the above option with the following additional options:

    1. Ability to save Link preference setups per app/host app/preset
    2. Ability to incorporate non-Link sync protocols in a Link network setup.
    3. Option to have Link sync based on transport controls.
    4. Link/sync options would have most common use cases as default with more complex options requiring a deeper level of app navigation so that the needs of people who have more common setups can easily set things up to their liking and people who want more customized/complex setups will have those options available without burdening other users who will not need, use, or want them.
    5. Be able to use my apps and hardware how I want without needing to know anything about Link.

    I would choose option five even though it's fantasy material for the foreseeable future.

    I agree with number 5 and the way to get there is by breaking down all of the different issues regarding sync and connectivity into smaller issues and adressing them one at a time, which is exactly what the poll on this thread is doing. Not one thread or poll is going to get us there.

    I think addressing specific protocol level issues one at a time to perfect different aspects of a music workflow is an approach a developer would use

    I see. I am a game dev so it makes sense that is how I would hit it.

  • [Deleted User][Deleted User]

    @AudioGus said:

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:

    @AudioGus said:

    @InfoCheck said:
    How about the option of some apps with Link like Patterning which enable you to turn off Link to enable either MIDI clock sync or IAA sync which may be preferable depending upon the particular setup you're running at the time. You can have a situation where an app such as AUM can host Patterning and you want Patterning to respond to AUM's transport controls so you'd set Patterning to IAA host sync. You may have another situation where you want Patterning to respond to MIDI clock sent out by MIDI hardware or an iOS sequencer that only sends out MIDI clock. You could have a situation where you start playing some other apps first and want Patterning to come in on the beat so Link would be preferred. The poll would be more useful if it reflected these options.

    I think for now I am ignoring midi clock in this poll and sticking to just Link. Gotta start somewhere and I just want to keep the Link only side simple.

    When you ignore MIDI clock sync, you're ignoring hybrid setups and in general the underlying issue with sync on iOS which is you have three different protocols that users need to navigate to be able to use all of their gear unless they limit themselves to Link only protocols. I prefer to be able to drive my music based upon what I want to do rather than some manufacturer's technical framework. It basically boils down to are the machines serving our needs or are we serving theirs?

    If the language the machines speak is too difficult to figure out, this can be a barrier to doing things the way we want. The whole point of the creation of the MIDI standard was to enable users to learn just one control protocol rather than having to learn each manufacturer's protocol and then figure out how to get all of those protocols in sync. I'd still prefer that app developers, operating systems, and hardware manufacturers all cooperate to make life easier for us so that sync becomes their problem to address rather than the musicians. Ideally musicians just need to know what they want to do. The less time spent delving into the underlying non-musical support structure the better.

    Out of curiosity, what options would you have added to the poll to reflect your points?

    I think for me it's difficult to address these issues with a poll like this unless you have an all of the above option with the following additional options:

    1. Ability to save Link preference setups per app/host app/preset
    2. Ability to incorporate non-Link sync protocols in a Link network setup.
    3. Option to have Link sync based on transport controls.
    4. Link/sync options would have most common use cases as default with more complex options requiring a deeper level of app navigation so that the needs of people who have more common setups can easily set things up to their liking and people who want more customized/complex setups will have those options available without burdening other users who will not need, use, or want them.
    5. Be able to use my apps and hardware how I want without needing to know anything about Link.

    I would choose option five even though it's fantasy material for the foreseeable future.

    I agree with number 5 and the way to get there is by breaking down all of the different issues regarding sync and connectivity into smaller issues and adressing them one at a time, which is exactly what the poll on this thread is doing. Not one thread or poll is going to get us there.

    I think addressing specific protocol level issues one at a time to perfect different aspects of a music workflow is an approach a developer would use

    I see. I am a game dev so it makes sense that is how I would hit it.

    That's very cool. Once again I do not want to impose or suggest my approach is anything but my point of view and other people can have more effective ways of addressing these issues than me.

  • ciancian

    You should either follow the spec (change the BPM to the current LINK BPM until the musician actively changes the BPM), or you should give the user the option to 'restore' the BPM to what they had before starting Link.

    What you definitely shouldn't do, as it breaks Link, is change the LINK Bpm silently.

  • [Deleted User][Deleted User]
    edited September 2017
    The user and all related content has been deleted.
Sign In or Register to comment.

© Vanilla Keystone Theme 2025