Photon AU is available

midiSequencer

thx for the feedback and sample. will get onto it today

midiSequencer

@wim was able to reproduce this once in AUM but damned if I can see it again?

Loops do wait on transport next bar - the beat position supplied by the host is used to determine that. I compensate for late notification (usually 0.02 beats) but wonder if AUM is skipping a render call or calling it too quickly (so I'm still playing the loop)?

Will keep trying to debug this

wim

@midiSequencer said:
@wim was able to reproduce this once in AUM but damned if I can see it again?

Loops do wait on transport next bar - the beat position supplied by the host is used to determine that. I compensate for late notification (usually 0.02 beats) but wonder if AUM is skipping a render call or calling it too quickly (so I'm still playing the loop)?

Will keep trying to debug this

Funny, the same test file is behaving better today here too. However, there was a very clear pattern to the more rare occurrences. The loop would play successfully 12 times, then skip a measure, play once more, then skip a measure, then repeat that sequence over and over.

Stopping and restarting the AUM transport did not reset the sequence. If I stopped the transport after loop number ten, it would still skip after loop number 12.

Stopping and restarting the Photon transport didn’t reset the count either. The skips still happened as scheduled per the AUM measure count.

So, then I stopped and rewound AUM’s transport, pressed play in Photon, then pressed play in AUM. The pattern of skipped measures is as follows.

3
16, 18     106, 108
31, 33     121, 123
46, 48     136, 138
61, 63
76, 78
91, 93

As you can see, after the first skip, 12 measures play, then skip one, play one, skip one ... repeat. But, the count is according to AUM’s measure count. Photon can be stopped in that period and it doesn’t affect the bars that those skips occur on.

Hope that helps.

Reminder: This is current production version of AUM, not the beta.

midiSequencer

@wim will try again not using AUM beta

Telstar5

@CracklePot said:

@SevenSystems said:

@CracklePot said:
I noticed someone left a 1-star review. This person seems to be opening the standalone and only getting access to the manual.
Complained about ‘only receiving a PDF file’.

"Looking forward" to that experience after release of my first Audio Unit! (my app store descriptions already begin with a 3-page disclaimer in all-caps stating that a brain is required, but I don't think that's enough for the level of stupidity that can be met in some dark corners of the userbase...)

I’m in, whatever your first AU app turns out to be.

Ditto: I’m in too!

wim

@midiSequencer said:
@wim will try again not using AUM beta

And ... now it’s working fine. Good luck with this one.
I’m flummoxed at how to consistently reproduce it.

supadom

@CracklePot said:
Well, I have it pretty much figured out, and it makes sense to me.
I hope it doesn’t change completely.

That’s exactly the problem with dramatically changing the way an app operates when it is already released. People who’ve already learnt it might not be too keen.

I just bought it and some things don’t make sense to me but I’m at early stages so could be user error.

Impressions so far though:

Feels like I’m seeing developers/advanced view. I think user should see half of the stuff there is.

The edit window should be bigger and always be in edit mode.

The default should be 1+4 bars with quantising on to 16.

Buffer terminology is confusing. There should be ‘clear pad’ or ‘clear loop’ command. I keep clearing buffer but it says nothing to clear while I can see the notes still there. Bug?

The best template I can think of is Loopy. I don’t mean the bunch of doughnuts but more how the loops are handled. So all the user needs is set the loop specifics, length, quantising and that’s all. Press record and you’re rocking.

Questions:

Could this be made to start and stop with the host?

Could you @midiSequencer do away with pads and just have one loop per Instance? It is AU after all.

Carnbot

The new interface should help hopefully when updated. I’m happy with multiple pads, one of the main uses is to sequence midi parts. This isn’t a looper really but a recorder, player and sequencer.

lukesleepwalker

@Carnbot said:
The new interface should help hopefully when updated. I’m happy with multiple pads, one of the main uses is to sequence midi parts. This isn’t a looper really but a recorder, player and sequencer.

This is a really important distinction. During the beta I kept wanting it to be a MIDI looper. When I finally gave in to Tony's actual vision of a record, play, sequence tool it all made more sense. There's obviously still room in the market for a simple MIDI looper that mimics Loopy functions.

supadom

@lukesleepwalker said:

@Carnbot said:
The new interface should help hopefully when updated. I’m happy with multiple pads, one of the main uses is to sequence midi parts. This isn’t a looper really but a recorder, player and sequencer.

This is a really important distinction. During the beta I kept wanting it to be a MIDI looper. When I finally gave in to Tony's actual vision of a record, play, sequence tool it all made more sense. There's obviously still room in the market for a simple MIDI looper that mimics Loopy functions.

May I add massive?

midiSequencer

The problem with Photon is it grew into three or more apps - hence it became more confusing in the UI trying to present these all at once. By satisfying a lot of requests it did become function heavy, but hey these requests came from our very own AB forum!

The recording is fine - it records your session - all midi channels in one go, saves them to a midi file which you can share & import. This is the real purpose of Photon.

The buffer display was added to give you a visual on what you recorded - important for step recording, but it was never meant to be a full editor.

Pads seemed like a good idea - after all you want to playback what you recorded, but its not a full launchpad of clips just yet.

Groove was an add on as was basic editing.

There are areas to improve (eg editing), but I need enough votes from ppl to justify it. At the moment I still have state saving & the UI on my list to deliver.

Carnbot

@supadom said:

@lukesleepwalker said:

@Carnbot said:
The new interface should help hopefully when updated. I’m happy with multiple pads, one of the main uses is to sequence midi parts. This isn’t a looper really but a recorder, player and sequencer.

This is a really important distinction. During the beta I kept wanting it to be a MIDI looper. When I finally gave in to Tony's actual vision of a record, play, sequence tool it all made more sense. There's obviously still room in the market for a simple MIDI looper that mimics Loopy functions.

May I add massive?

Yeah I see this more as a midi composing tool.. There will be a more dedicated midi FX AU for live looping
soon I'm sure. I would think AudioVeek piano roll might work better here maybe? I haven't tried that yet though, release is imminent.

midiSequencer

@supadom said:
Questions:

Could this be made to start and stop with the host?

It does - set the pad to "Start on Bar" or "Start on Beat"

Could you @midiSequencer do away with pads and just have one loop per Instance? It is AU after all.

Having now delivered 6 pads - you don't have to use the other 5

Carnbot

Statesaving is huge though, I'm holding off using it a lot until then because reloading everything is a big workflow killer right now.

supadom

@midiSequencer said:
The problem with Photon is it grew into three or more apps - hence it became more confusing in the UI trying to present these all at once. By satisfying a lot of requests it did become function heavy, but hey these requests came from our very own AB forum!

The recording is fine - it records your session - all midi channels in one go, saves them to a midi file which you can share & import. This is the real purpose of Photon.

The buffer display was added to give you a visual on what you recorded - important for step recording, but it was never meant to be a full editor.

Pads seemed like a good idea - after all you want to playback what you recorded, but its not a full launchpad of clips just yet.

Groove was an add on as was basic editing.

There are areas to improve (eg editing), but I need enough votes from ppl to justify it. At the moment I still have state saving & the UI on my list to deliver.

Yes, I totally agree. This is why I think there must be a very strong core vision for the app to be coherent from start to finish. Because we're using these tools in so many different ways it is hard to make something simple that does one thing well.

@Carnbot Yes it's true it is my fault for expecting it to be a midi looper as opposed to recorder but to be completely honest, in generic electronic music aren't we dealing with nothing but a bunch of loops? When you export a midi file don't you want it to be a precise loop to just slot into your daw or whatever?

Anyhow, as mentioned before, I've only just dipped my toes and these are the impressions. I must say I didn't expect to get stuck so soon. Will see how it goes.

Thanks @midiSequencer for your ambitious effort to try and please everyone (no sarcasm intended)

lukesleepwalker

@midiSequencer said:
The problem with Photon is it grew into three or more apps - hence it became more confusing in the UI trying to present these all at once. By satisfying a lot of requests it did become function heavy, but hey these requests came from our very own AB forum!

The recording is fine - it records your session - all midi channels in one go, saves them to a midi file which you can share & import. This is the real purpose of Photon.

The buffer display was added to give you a visual on what you recorded - important for step recording, but it was never meant to be a full editor.

Pads seemed like a good idea - after all you want to playback what you recorded, but its not a full launchpad of clips just yet.

Groove was an add on as was basic editing.

There are areas to improve (eg editing), but I need enough votes from ppl to justify it. At the moment I still have state saving & the UI on my list to deliver.

State saving is essential regardless so safe bet to get that out!

The looping thing is interesting. You may be able to nail it through subtraction and UI changes. Package it up as a separate app and make some extra $$$.

supadom

@lukesleepwalker said:

@midiSequencer said:
The problem with Photon is it grew into three or more apps - hence it became more confusing in the UI trying to present these all at once. By satisfying a lot of requests it did become function heavy, but hey these requests came from our very own AB forum!

The recording is fine - it records your session - all midi channels in one go, saves them to a midi file which you can share & import. This is the real purpose of Photon.

The buffer display was added to give you a visual on what you recorded - important for step recording, but it was never meant to be a full editor.

Pads seemed like a good idea - after all you want to playback what you recorded, but its not a full launchpad of clips just yet.

Groove was an add on as was basic editing.

There are areas to improve (eg editing), but I need enough votes from ppl to justify it. At the moment I still have state saving & the UI on my list to deliver.

State saving is essential regardless so safe bet to get that out!

The looping thing is interesting. You may be able to nail it through subtraction and UI changes. Package it up as a separate app and make some extra $$$.

Yup, AD do that with their apps all the time. App design is definitely their strong side.

midiSequencer

yeah let me get state saving done first.

I'm working on a new AU custom key scaling app(almost done now) to test the approach & the ui auto-rescaling as Photon is rather complex.

midiSequencer

@supadom said:

Yes, I totally agree. This is why I think there must be a very strong core vision for the app to be coherent from start to finish. Because we're using these tools in so many different ways it is hard to make something simple that does one thing well.

Yep scope creep got the better of me!

Thanks @midiSequencer for your ambitious effort to try and please everyone (no sarcasm intended)

np - I only loop step sequences not midi in my music so rely on you folks to guide me!

lukesleepwalker

Your attitude is great, @midiSequencer!

wim

I think the essentials of the simplified workflow that @supadom describes have been added with the Number of Measures to Record, Start on Bar, and Send to Pad options. However, those aren’t the defaults. All a simplified workflow view would need would be these options enabled by default:

• Real-time Record: Wait for next bar
• Real-time Record: Send to pad 1
• Real-time Record: Number of Bars to record (default to 4?)
• Real-time Record: (Quantize 1/16 as default?) Maybe not...
• Pad 1: Start on Bar
• Pad 1: Auto

I think if these were simply the defaults it might go a long way toward overcoming the complexity people perceive when first looking into the app. However, it might be worth considering having a “Simple” mode with only those options showing and an “Advanced” mode with all the bells and whistles.

Just thinking out loud.

I actually like the way things work now that I understand it. The defaults aren’t the best for what I do, but changing them gets habitual after a bit. Being able to save presets would streamline that.

Carnbot

@supadom said:

@midiSequencer said:
The problem with Photon is it grew into three or more apps - hence it became more confusing in the UI trying to present these all at once. By satisfying a lot of requests it did become function heavy, but hey these requests came from our very own AB forum!

The recording is fine - it records your session - all midi channels in one go, saves them to a midi file which you can share & import. This is the real purpose of Photon.

The buffer display was added to give you a visual on what you recorded - important for step recording, but it was never meant to be a full editor.

Pads seemed like a good idea - after all you want to playback what you recorded, but its not a full launchpad of clips just yet.

Groove was an add on as was basic editing.

There are areas to improve (eg editing), but I need enough votes from ppl to justify it. At the moment I still have state saving & the UI on my list to deliver.

Yes, I totally agree. This is why I think there must be a very strong core vision for the app to be coherent from start to finish. Because we're using these tools in so many different ways it is hard to make something simple that does one thing well.

@Carnbot Yes it's true it is my fault for expecting it to be a midi looper as opposed to recorder but to be completely honest, in generic electronic music aren't we dealing with nothing but a bunch of loops? When you export a midi file don't you want it to be a precise loop to just slot into your daw or whatever?

Anyhow, as mentioned before, I've only just dipped my toes and these are the impressions. I must say I didn't expect to get stuck so soon. Will see how it goes.

Thanks @midiSequencer for your ambitious effort to try and please everyone (no sarcasm intended)

I personally think Photon is designed best for where you've got various sequences together from other sources, eg Quantum, Modstep etc and you want to record/playback/arrange them in one host. It's more considered than a live looper. I could see something like Fugue machine being better suited to that if it ever gets record input.

@supadom Have you got Thesys?
It can live step record and has automation for looping, might be worth a look for basic looping. It's fiddly but fun once you get it all set up via midi.

midiSequencer

@wim said:
I think the essentials of the simplified workflow that @supadom describes have been added with the Number of Measures to Record, Start on Bar, and Send to Pad options. However, those aren’t the defaults. All a simplified workflow view would need would be these options enabled by default:

• Real-time Record: Wait for next bar
• Real-time Record: Send to pad 1
• Real-time Record: Number of Bars to record (default to 4?)
• Real-time Record: (Quantize 1/16 as default?) Maybe not...
• Pad 1: Start on Bar
• Pad 1: Auto

I think if these were simply the defaults it might go a long way toward overcoming the complexity people perceive when first looking into the app. However, it might be worth considering having a “Simple” mode with only those options showing and an “Advanced” mode with all the bells and whistles.

Just thinking out loud.

I actually like the way things work now that I understand it. The defaults aren’t the best for what I do, but changing them gets habitual after a bit. Being able to save presets would streamline that.

Some of these settings don't currently get saved as presets, but if you set this up in a new instance and save it it does save/restore the
Real-time Record: Number of Bars to record (default to 4?)
Real-time Record: (Quantize 1/16 as default?) Maybe not...
Pad x: Start on Bar
Pad x: Auto
etc.

So I need to add just the Record pre & post as AU Parameters and presets should allow you to work with your preferred default. I will add that setting as a factory preset.

When the UI is reworked it needs to have a simple mode (so fits on an iPhone) - so yes tucking away some of these parameters that don't need exposing all at once.

wim

@midiSequencer said:

@wim said:
I think the essentials of the simplified workflow that @supadom describes have been added with the Number of Measures to Record, Start on Bar, and Send to Pad options. However, those aren’t the defaults. All a simplified workflow view would need would be these options enabled by default:

• Real-time Record: Wait for next bar
• Real-time Record: Send to pad 1
• Real-time Record: Number of Bars to record (default to 4?)
• Real-time Record: (Quantize 1/16 as default?) Maybe not...
• Pad 1: Start on Bar
• Pad 1: Auto

I think if these were simply the defaults it might go a long way toward overcoming the complexity people perceive when first looking into the app. However, it might be worth considering having a “Simple” mode with only those options showing and an “Advanced” mode with all the bells and whistles.

Just thinking out loud.

I actually like the way things work now that I understand it. The defaults aren’t the best for what I do, but changing them gets habitual after a bit. Being able to save presets would streamline that.

Some of these settings don't currently get saved as presets, but if you set this up in a new instance and save it it does save/restore the
Real-time Record: Number of Bars to record (default to 4?)
Real-time Record: (Quantize 1/16 as default?) Maybe not...
Pad x: Start on Bar
Pad x: Auto
etc.

So I need to add just the Record pre & post as AU Parameters and presets should allow you to work with your preferred default. I will add that setting as a factory preset.

When the UI is reworked it needs to have a simple mode (so fits on an iPhone) - so yes tucking away some of these parameters that don't need exposing all at once.

Ahh ... I didn’t even realize there was the ability to save presets since I mainly use Photon in Audiobus, and do not see a preset menu there.

User presets saved in AUM don’t show in other hosts such as Ape Matrix, do they?

midiSequencer

@wim said:

Ahh ... I didn’t even realize there was the ability to save presets since I mainly use Photon in Audiobus, and do not see a preset menu there.

User presets saved in AUM don’t show in other hosts such as Ape Matrix, do they?

In AUM press the + in the presets menu.
I've added Record Post as an AU Parameter now, but noticing that presets don't always restore (it should update the UI too) - will fix this.

No you can't share presets between hosts afaik.

espiegel123

@midiSequencer said:

@wim said:

Ahh ... I didn’t even realize there was the ability to save presets since I mainly use Photon in Audiobus, and do not see a preset menu there.

User presets saved in AUM don’t show in other hosts such as Ape Matrix, do they?

In AUM press the + in the presets menu.
I've added Record Post as an AU Parameter now, but noticing that presets don't always restore (it should update the UI too) - will fix this.

No you can't share presets between hosts afaik.

Are the presets supposed to recall the MIDI stored in the pads?

midiSequencer

@espiegel123 said:
Are the presets supposed to recall the MIDI stored in the pads?

I haven't coded them yet (its quite complicated to do) - they just focus on the exposed AU Parameters. Its next on my list to do so apple can create restore points. Personally I save everything anyway, but understand the time saving aspect of state saving.

So if I code midi files in state saving, you also get them saved as Presets

wim

@midiSequencer said:

@wim said:

Ahh ... I didn’t even realize there was the ability to save presets since I mainly use Photon in Audiobus, and do not see a preset menu there.

User presets saved in AUM don’t show in other hosts such as Ape Matrix, do they?

In AUM press the + in the presets menu.
I've added Record Post as an AU Parameter now, but noticing that presets don't always restore (it should update the UI too) - will fix this.

No you can't share presets between hosts afaik.

Thanks, I’m familiar with the preset saving method in AUM.mi just never thought to use it since no similar function exists for Photon in AudioBus (though it does for some other apps). I think why is more of a question for @michael.
Thanks again for the responses, added features, and help!

Carnbot

@wim said:

@midiSequencer said:

I can save user AB presets for Photon in current beta, maybe that's not possible in current release version?

wim

@Carnbot said:

@wim said:

@midiSequencer said:

I can save user AB presets for Photon in current beta, maybe that's not possible in current release version?

AB beta or Photon beta?