Loopy Pro as a midi source in AUM

solncekreeze

@espiegel123 said:
Make sure you have turned on state saving->Whole project

in the loopy pro AU system settings

https://www.dropbox.com/s/6ksqvuzkl0b205g/Streambytes test midi LP.aumproj?dl=0

Fixed it.

espiegel123

@solncekreeze said:

@espiegel123 said:
Make sure you have turned on state saving->Whole project

in the loopy pro AU system settings

https://www.dropbox.com/s/6ksqvuzkl0b205g/Streambytes test midi LP.aumproj?dl=0

Fixed it.

It works fine for me. Please follow these steps, the order matters:

• open the Aum project
• turn Streambyter to the monitor page before doing anything else
• tap each of the buttons you created: i see the midi sent by both
• tap the donut in your loopy pro project so that it is "stopped"/off
• tap the donut again to play enable it. this triggers the play follow action. i see the cc in the streambyter monitor.

I end up with something like this:

espiegel123

Note that play follow actions are triggered when a loop becomes play enabled. The play follow action in your project doesn't fire when play starts because it was already play enabled.

@Michael : it seems like it might be a bug that a play follow action doesn't trigger at all when you open a project and press play if clips are already play enabled. It seems like they should fire when transport starts in this case, maybe?

solncekreeze

@espiegel123 said:
Note that play follow actions are triggered when a loop becomes play enabled. The play follow action in your project doesn't fire when play starts because it was already play enabled.

@Michael : it seems like it might be a bug that a play follow action doesn't trigger at all when you open a project and press play if clips are already play enabled. It seems like they should fire when transport starts in this case, maybe?

Yes, that's how it works. But it turns out that the signal is sent once and after passing the magnifier is not repeated. And you need VS to react to the notes that sound in the magnifier. Switched to the notes and nothing changes. It turns out that the signal will be sent only once? Let's say the drum part is for VS to react to a barrel (one channel), to a Hit (another channel). But not at the beginning of the passage of the magnifier, but at the sounding notes. It's probably impossible.

espiegel123

@solncekreeze said:

@espiegel123 said:
Note that play follow actions are triggered when a loop becomes play enabled. The play follow action in your project doesn't fire when play starts because it was already play enabled.

@Michael : it seems like it might be a bug that a play follow action doesn't trigger at all when you open a project and press play if clips are already play enabled. It seems like they should fire when transport starts in this case, maybe?

Yes, that's how it works. But it turns out that the signal is sent once and after passing the magnifier is not repeated. And you need VS to react to the notes that sound in the magnifier. Switched to the notes and nothing changes. It turns out that the signal will be sent only once? Let's say the drum part is for VS to react to a barrel (one channel), to a Hit (another channel). But not at the beginning of the passage of the magnifier, but at the sounding notes. It's probably impossible.

I am not sure what you are trying to say. But if you want the play follow action triggered each time a clip is at its beginning, set the clips to play once mode and retrigger them as needed.

There is likely a way to accomplish what you want but might require a different approach than you imagined.

Play follow actions are triggered by a clip entering the play state.

solncekreeze

@espiegel123 said:

@solncekreeze said:

@espiegel123 said:
Note that play follow actions are triggered when a loop becomes play enabled. The play follow action in your project doesn't fire when play starts because it was already play enabled.

@Michael : it seems like it might be a bug that a play follow action doesn't trigger at all when you open a project and press play if clips are already play enabled. It seems like they should fire when transport starts in this case, maybe?

Yes, that's how it works. But it turns out that the signal is sent once and after passing the magnifier is not repeated. And you need VS to react to the notes that sound in the magnifier. Switched to the notes and nothing changes. It turns out that the signal will be sent only once? Let's say the drum part is for VS to react to a barrel (one channel), to a Hit (another channel). But not at the beginning of the passage of the magnifier, but at the sounding notes. It's probably impossible.

I am not sure what you are trying to say. But if you want the play follow action triggered each time a clip is at its beginning, set the clips to play once mode and retrigger them as needed.

There is likely a way to accomplish what you want but might require a different approach than you imagined.

Play follow actions are triggered by a clip entering the play state.

You got it right. Play once can be started, but it's inconvenient. I'll try with the controller. I hope in the future it will be possible to do it not so difficult. I want to say a big thank you for your help. I learned a lot of things. I'm just waiting for Launchpad and I need to deepen my knowledge of midi🙌

espiegel123

@solncekreeze : if you need midi sent out each time through the loop rather than when the loop becomes active, you might want to consider using LK or Atom to trigger the loops.

solncekreeze

@espiegel123 said:
@solncekreeze : if you need midi sent out each time through the loop rather than when the loop becomes active, you might want to consider using LK or Atom to trigger the loops.

Thanks for the advice. I have already quickly set up Drambo by channels-it works as I need it. But LP is more convenient for sessions (including what concerns the use of the controller and colors). Drambo doesn't have that. Atom 2 will try. But LP is good visually and intuitively. I hope midi out will appear (there seem to be plans in the roadmap).

espiegel123

@solncekreeze said:

@espiegel123 said:
@solncekreeze : if you need midi sent out each time through the loop rather than when the loop becomes active, you might want to consider using LK or Atom to trigger the loops.

Thanks for the advice. I have already quickly set up Drambo by channels-it works as I need it. But LP is more convenient for sessions (including what concerns the use of the controller and colors). Drambo doesn't have that. Atom 2 will try. But LP is good visually and intuitively. I hope midi out will appear (there seem to be plans in the roadmap).

Midi out will make it more convenient, but you can already accomplish the same thing.

solncekreeze

@espiegel123 said:

@solncekreeze said:

@espiegel123 said:
@solncekreeze : if you need midi sent out each time through the loop rather than when the loop becomes active, you might want to consider using LK or Atom to trigger the loops.

Thanks for the advice. I have already quickly set up Drambo by channels-it works as I need it. But LP is more convenient for sessions (including what concerns the use of the controller and colors). Drambo doesn't have that. Atom 2 will try. But LP is good visually and intuitively. I hope midi out will appear (there seem to be plans in the roadmap).

Midi out will make it more convenient, but you can already accomplish the same thing.

I agree. We will understand further.

Michael

@espiegel123 said:
Note that play follow actions are triggered when a loop becomes play enabled. The play follow action in your project doesn't fire when play starts because it was already play enabled.

@Michael : it seems like it might be a bug that a play follow action doesn't trigger at all when you open a project and press play if clips are already play enabled. It seems like they should fire when transport starts in this case, maybe?

That’s a fair point! But might it not break some setups if a clip enters play state while the clock is paused and sends a follow action, then does it again when the clock unpauses? At least in one interpretation the clip is already “playing” but just paused while the clock is not running. I can imagine some people making templates that will stop or start other clips, enable/disable effects, etc when a clip plays, and they might be surprised that the action runs if they pause and then unpause…

espiegel123

@Michael said:

@espiegel123 said:
Note that play follow actions are triggered when a loop becomes play enabled. The play follow action in your project doesn't fire when play starts because it was already play enabled.

@Michael : it seems like it might be a bug that a play follow action doesn't trigger at all when you open a project and press play if clips are already play enabled. It seems like they should fire when transport starts in this case, maybe?

That’s a fair point! But might it not break some setups if a clip enters play state while the clock is paused and sends a follow action, then does it again when the clock unpauses? At least in one interpretation the clip is already “playing” but just paused while the clock is not running. I can imagine some people making templates that will stop or start other clips, enable/disable effects, etc when a clip plays, and they might be surprised that the action runs if they pause and then unpause…

The case that I am thinking of us different. You open a project that has clips with follow actions. Those clips are play-enabled when you open the project. You press play. It seems like in this case where transport hasn't run before (and so from user perspective they aren't paused) those follow actions should probably fire when you press play.

I have no idea what should happen when the clock pauses and restarts.

The points you make are all important to consider.

Michael

@espiegel123 said:

@Michael said:

@espiegel123 said:
Note that play follow actions are triggered when a loop becomes play enabled. The play follow action in your project doesn't fire when play starts because it was already play enabled.

@Michael : it seems like it might be a bug that a play follow action doesn't trigger at all when you open a project and press play if clips are already play enabled. It seems like they should fire when transport starts in this case, maybe?

That’s a fair point! But might it not break some setups if a clip enters play state while the clock is paused and sends a follow action, then does it again when the clock unpauses? At least in one interpretation the clip is already “playing” but just paused while the clock is not running. I can imagine some people making templates that will stop or start other clips, enable/disable effects, etc when a clip plays, and they might be surprised that the action runs if they pause and then unpause…

The case that I am thinking of us different. You open a project that has clips with follow actions. Those clips are play-enabled when you open the project. You press play. It seems like in this case where transport hasn't run before (and so from user perspective they aren't paused) those follow actions should probably fire when you press play.

I have no idea what should happen when the clock pauses and restarts.

The points you make are all important to consider.

Ah, yes, fair enough. Hmm. I feel like there are reasonably compelling arguments on either side of that one too – if there are follow actions set to change the state of the project, then I'm not sure that running them when starting transport would necessarily be the expected thing. I have a feeling this may be one of those judgement calls, try to figure out just what most people would expect/want. I'm a little nervous about changing it, in case it breaks something. Maybe it should be a setting somewhere.

espiegel123

@Michael said:

@espiegel123 said:

@Michael said:

@espiegel123 said:
Note that play follow actions are triggered when a loop becomes play enabled. The play follow action in your project doesn't fire when play starts because it was already play enabled.

@Michael : it seems like it might be a bug that a play follow action doesn't trigger at all when you open a project and press play if clips are already play enabled. It seems like they should fire when transport starts in this case, maybe?

That’s a fair point! But might it not break some setups if a clip enters play state while the clock is paused and sends a follow action, then does it again when the clock unpauses? At least in one interpretation the clip is already “playing” but just paused while the clock is not running. I can imagine some people making templates that will stop or start other clips, enable/disable effects, etc when a clip plays, and they might be surprised that the action runs if they pause and then unpause…

The case that I am thinking of us different. You open a project that has clips with follow actions. Those clips are play-enabled when you open the project. You press play. It seems like in this case where transport hasn't run before (and so from user perspective they aren't paused) those follow actions should probably fire when you press play.

I have no idea what should happen when the clock pauses and restarts.

The points you make are all important to consider.

Ah, yes, fair enough. Hmm. I feel like there are reasonably compelling arguments on either side of that one too – if there are follow actions set to change the state of the project, then I'm not sure that running them when starting transport would necessarily be the expected thing. I have a feeling this may be one of those judgement calls, try to figure out just what most people would expect/want. I'm a little nervous about changing it, in case it breaks something. Maybe it should be a setting somewhere.

Maybe a preference for the time-being? Or better maybe not to do anything hasty and a refinement to play follow actions that is robust. As there are pretty legitimate use-cases for both styles. And, I kind of feel like “play enable” and “playback start” (with optional pre-start) should be different actions.