ATOM Piano Roll update is coming soon

RajahP

Seeing that there may be a little wait until release... Are ATOM v1 files compatible with V2.. will we be able to import those files from ATOM 1? The reason being, One can continue to record files in ATOM v1, knowing that they can be used when v2 is released...

This might help the wait.

blueveek

@ecamburn said:
Lo these many years I've searched high and low for the app that accommodates the mighty 17th note. The quest has ended.

Check this out

blueveek

@Skyblazer said:

Yes this is my thinking too, would it be sufficient just making the whole UI keyboard/controller navigate-able?

ecamburn

Brain hurting. Just recently subscribed to David Bruce. Love his style and content.

Skyblazer

@blueveek You mean, making the piano roll window keyboard/controller navigate-able with MIDI actions, some of which may not correspond to onscreen buttons? Yes. Then if somebody wants that level of control, they'll have it. And if they don't, the UI won't be too cluttered by additional buttons.

Maybe it could be just the four directions, and a toggle button for shifting between "semitones and quarter notes" and "octaves and bars", instead of 8 parameters. And if you hold a direction for ~2.5 seconds, it scrolls by that increment every ~0.75 seconds. (I'm just guessing, on the timing.)

cian

@blueveek - Messiaen does this stuff too. It's pretty cool.

audiblevideo

@blueveek you have until October 25th. I’d like to have some time to enjoy making some music before all hell breaks loose on November 3rd.

😂😂😂😂😭😭😭😭😭😶😐

Please

ecamburn

@blueveek ever considered changing your handle to iosmidigod?

Gavinski

@blueveek I'd certainly appreciate the mpe stuff but it wouldn't be necessary for the initial release maybe, if too time consuming.

I really appreciate that you are trying to get everything right before release, it's very annoying for users when apps come out with too many bugs and flaws. Take your time, do things your way. 👌

mlau

@blueveek if i have let’s say 5 instances of atom running, will there be a way to change the scale at once on each and every instance ?

Pierre118

@blueveek MPE would be great. A release around Xmas would be wonderful, take your time to finish this.

noob

Gimmie this app now boi. Now.

Krupa

MPE would be great but I’d be happy to get CC and the clip/layers stuff sooner, it’s all looking ace from the screenshots so far!

[Deleted User]

I’m also very excited about this.
MPE would be great but I can definitely wait for it.

blueveek

@Skyblazer said:
@blueveek You mean, making the piano roll window keyboard/controller navigate-able with MIDI actions, some of which may not correspond to onscreen buttons? Yes. Then if somebody wants that level of control, they'll have it. And if they don't, the UI won't be too cluttered by additional buttons.

Maybe it could be just the four directions, and a toggle button for shifting between "semitones and quarter notes" and "octaves and bars", instead of 8 parameters. And if you hold a direction for ~2.5 seconds, it scrolls by that increment every ~0.75 seconds. (I'm just guessing, on the timing.)

Yes. This is a power user feature (don't even get me started on how few users actually use keyboard shortcuts, something I repeatedly realise in my day-to-day job). I do want to enable this, I want it for myself too, but to avoid feature creep I'll add it to the "v2.1" queue

blueveek

@mlau said:
@blueveek if i have let’s say 5 instances of atom running, will there be a way to change the scale at once on each and every instance ?

This is a really interesting feature that I'm thinking about more broadly: it's useful changing some state across instances, sometimes, like the loop interval and, as you've noted, scales.

I'm interested in hearing your suggestions for what the UX could be here (and still enable changing this per-instance). Technically it's simple to implement, I'm more concerned with the user interaction.

espiegel123

@blueveek said:

@mlau said:
@blueveek if i have let’s say 5 instances of atom running, will there be a way to change the scale at once on each and every instance ?

This is a really interesting feature that I'm thinking about more broadly: it's useful changing some state across instances, sometimes, like the loop interval and, as you've noted, scales.

I'm interested in hearing your suggestions for what the UX could be here (and still enable changing this per-instance). Technically it's simple to implement, I'm more concerned with the user interaction.

If you those parameters set table via AU parameters, you can avoid the plugin communicating to the other plugins...you could even create a lightweight commander plugin that sends the requisite MIDI.

blueveek

@espiegel123 said:

@blueveek said:

@mlau said:
@blueveek if i have let’s say 5 instances of atom running, will there be a way to change the scale at once on each and every instance ?

This is a really interesting feature that I'm thinking about more broadly: it's useful changing some state across instances, sometimes, like the loop interval and, as you've noted, scales.

I'm interested in hearing your suggestions for what the UX could be here (and still enable changing this per-instance). Technically it's simple to implement, I'm more concerned with the user interaction.

If you those parameters set table via AU parameters, you can avoid the plugin communicating to the other plugins...you could even create a lightweight commander plugin that sends the requisite MIDI.

If I understand correctly, in terms of UX (which is what I'm interested in, the technicals are not the problem), users would have to wire one Atom into the other(s) to make this work. I think that can easily get out of hand, and requires an extra setup step (who has time for that?) but I wonder what others think.

espiegel123

@blueveek said:

@espiegel123 said:

@blueveek said:

@mlau said:
@blueveek if i have let’s say 5 instances of atom running, will there be a way to change the scale at once on each and every instance ?

This is a really interesting feature that I'm thinking about more broadly: it's useful changing some state across instances, sometimes, like the loop interval and, as you've noted, scales.

I'm interested in hearing your suggestions for what the UX could be here (and still enable changing this per-instance). Technically it's simple to implement, I'm more concerned with the user interaction.

If you those parameters set table via AU parameters, you can avoid the plugin communicating to the other plugins...you could even create a lightweight commander plugin that sends the requisite MIDI.

If I understand correctly, in terms of UX (which is what I'm interested in, the technicals are not the problem), users would have to wire one Atom into the other(s) to make this work. I think that can easily get out of hand, and requires an extra setup step (who has time for that?) but I wonder what others think.

I guess for me, a simple separate AU with an uncluttered ui that I can connect or not to any/all of my ATOM instances would probably be pleasant. ATOM already has a nicely rich interface -- it seems like adding this sort of functionality (and figuring out the UX for picking which instances are connected) could get cluttered. I guess I find simple modules elegant and less confusing than modules that get overstuff. But maybe that's just me.

Korakios

Long press on the function could apply to all layers.
It's better than a separate button that you may forget it's engaged, unless it blinks red with an 8bit sound alarm

Skyblazer

@blueveek said:

@Skyblazer said:
@blueveek You mean, making the piano roll window keyboard/controller navigate-able with MIDI actions, some of which may not correspond to onscreen buttons? Yes. Then if somebody wants that level of control, they'll have it. And if they don't, the UI won't be too cluttered by additional buttons.

Maybe it could be just the four directions, and a toggle button for shifting between "semitones and quarter notes" and "octaves and bars", instead of 8 parameters. And if you hold a direction for ~2.5 seconds, it scrolls by that increment every ~0.75 seconds. (I'm just guessing, on the timing.)

Yes. This is a power user feature (don't even get me started on how few users actually use keyboard shortcuts, something I repeatedly realise in my day-to-day job). I do want to enable this, I want it for myself too, but to avoid feature creep I'll add it to the "v2.1" queue

Awesome! Thank you so much. I think there will be more and more "power users" over time. On average, musicians seem to be more educated today than they were ten years ago.

mlau

@blueveek i’m glad you like this idea ! As for the UX, am short of ideas at the moment. Maybe someone could help with this ? @iOSTRAKON @Gavinski @MdM @cian ?

Gavinski

@mlau said:
@blueveek i’m glad you like this idea ! As for the UX, am short of ideas at the moment. Maybe someone could help with this ? @iOSTRAKON @Gavinski @MdM @cian ?

No idea!

ExAsperis99

@blueveek said:

@espiegel123 said:

@blueveek said:

@mlau said:
@blueveek if i have let’s say 5 instances of atom running, will there be a way to change the scale at once on each and every instance ?

This is a really interesting feature that I'm thinking about more broadly: it's useful changing some state across instances, sometimes, like the loop interval and, as you've noted, scales.

I'm interested in hearing your suggestions for what the UX could be here (and still enable changing this per-instance). Technically it's simple to implement, I'm more concerned with the user interaction.

If you those parameters set table via AU parameters, you can avoid the plugin communicating to the other plugins...you could even create a lightweight commander plugin that sends the requisite MIDI.

If I understand correctly, in terms of UX (which is what I'm interested in, the technicals are not the problem), users would have to wire one Atom into the other(s) to make this work. I think that can easily get out of hand, and requires an extra setup step (who has time for that?) but I wonder what others think.

I see why this is appealing, to have, say, a governor Atom that rules them all. But that's essentially what LK is already. The joy of Atom is that it's VERY easy to just open a window and bang out a melody or a bassline. It might stick, it might not. But no instance has have a codified "official" feeling, which is why I find Atom so inspiring. There's no hierarchy of the clips and that is very freeing.
Does that make sense?

tk32

@blueveek said:

If I understand correctly, in terms of UX (which is what I'm interested in, the technicals are not the problem), users would have to wire one Atom into the other(s) to make this work. I think that can easily get out of hand, and requires an extra setup step (who has time for that?) but I wonder what others think.

My humble UX suggestion here would be to automatically treat certain parameters as globals (such as scale/transpose), and then have padlocks (toggle on/off) that allow users to lock them for individual Atom instances.

Effectively a make unique toggle

cian

@tk32 said:

@blueveek said:

If I understand correctly, in terms of UX (which is what I'm interested in, the technicals are not the problem), users would have to wire one Atom into the other(s) to make this work. I think that can easily get out of hand, and requires an extra setup step (who has time for that?) but I wonder what others think.

My humble UX suggestion here would be to automatically treat certain parameters as globals (such as scale/transpose), and then have padlocks (toggle on/off) that allow users to lock them for individual Atom instances.

Effectively a make unique toggle

Yes I was going to suggest something similar.

A slightly more advanced approach would be to allow the user to link certain instances, sot hat a change to one would affect all of them.

For anything more complicated the user can work out a solution using Midi. Mozaic could handle that. Support the common case, provide hooks for anything else and let the user work it out.

Samu

@tk32 said:

@blueveek said:

If I understand correctly, in terms of UX (which is what I'm interested in, the technicals are not the problem), users would have to wire one Atom into the other(s) to make this work. I think that can easily get out of hand, and requires an extra setup step (who has time for that?) but I wonder what others think.

My humble UX suggestion here would be to automatically treat certain parameters as globals (such as scale/transpose), and then have padlocks (toggle on/off) that allow users to lock them for individual Atom instances.

That could work but I'm allergic to changing too many parameters automagically especially if it affects multiple instances.

Let's say that you've created a bunch of patterns in a set scale but 'forgot to lock' them and need a chromatic scale for drums?
Now that's something that would annoy the heck out of me especially if scale & key quantize is also automatic.

If the global changes across all instances are implemented I suggest it's 'optional' and has to be enabled per instance.
(Ie. 'instance lock' should be on by default).

Regarding 'scales' in general what about a 'Gadget Style' number of notes per scale setting to keep things neat and tidy?

I do get that it's practical from performance perspective to be able to change scale and do key quantize on the fly but it's a bloody nightmare when editing stuff if the scale changes automagically when editing the events.
(It's like some loonie would change the grid size on the fly when adding events).

Then again it's just my opinion...

tk32

Samu makes a good point (as usual )

I think I agree. How about this revised idea...

Let's say all Atom instances begin as unique entities, but there is the ability to attach certain parameters to a shared global value. (it could be shown visually next to the parameter as a link/chain icon)

If you modify a linked/chained parameter, it affects all other instances that also have those parameters chained.

Atom polymorphism.

NB - when you enable a chained parameter for the first time it must try to read the current global value (if one already exists) before setting it's own current value as the new global.

Samu

A 'link/chain' icon is definitely more logical than a 'lock' icon since a lock usually means 'U can't change this' without unlocking first...

To keep the UI clean without additional icons one way would be to long-tap on a value to sync it across all the instances.

This way we'd get individual instances with a quick way to sync the parameters and changing one instances would not mess with the others unless the user interacts with the value using a 'long tap'.

Another option still to make editing easier would be to have a simple 'scale/chromatic' switch for the vertical ruler which does not affect the actual scale setting. (This is roughly how ZenBeats does it).

ExAsperis99

DANGER WILL ROBINSON! MISSION CREEP! ABORT, ABORT.