Atom piano roll is here !

SevenSystems

@Samu said:

@SevenSystems said:
I'm not sure why limiting zooming to "one axis at a time depending on movement angle" would be an advantage? It's artificially limiting... if you only want to zoom horizontally, you simply move your fingers only horizontally... if there's a slight vertical component too, then that can't be a problem because all that happens is that vertical zoom changes slightly? (and vice versa). But maybe I'm missing something...

The slightly added vertical/horizontal movement can get super annoying, let me explain...

Presume that you've carefully set the vertical zoom to cover say 24 'rows'(ie. 2 octaves) and use all of them.
Now if you 'zoom' and there is some vertical movement during zoom those rows might go 'off screen'.

The alternate would also be true but in the horizontal orientation.
Ie. you carefully set the 'width' of the screen to cover 1 bar at 16th steps but need to do vertical zoom to reach all the keys).

For touch-screens to avoid un-intentional panning/scrolling a 'X/Y Lock' is a good idea complemented with a 'page up/down/left/right' to preserve the zoom ratio.

But then again, that's just me...

OK, so if the angle of line of movement between fingers is more horizontal than vertical (>45 deg), lock the zoom to horizontal until fingers lifted off... (same for vertical). As long as that's a user setting somewhere in the app, it's a good thing to have I guess. Adding to the roadmap

Paa89

@blueveek said:

@Paa89 said:

@blueveek said
I pondering on whether to allow configuring the vertical divisions opacity, or simply creating a white theme. Not sure which is better, I'm leaning slightly towards just implementing a white theme.

Anyone else have any preference here?

Hello there @blueveek the white theme would be perfect.
And aslo if possible, could you make some to zoom in and out like the way Cubasis piano roll works?
The current way you have is that the whole piano roll becomes small or big .
Would be nice to be able to zoom in sections.

Agreed, this is one of those features where some people love it, some people prefer it the "old" way.

Decoupling vertical/horizontal zooming is something that I've received requests for, but I'm seriously disliking the way pinch gestures currently work with other piano rolls on iOS. I think that having a single gesture for simultaneous independent horizontal and vertical zooming is fundamentally bad UX with touch screens, so I'm exploring different ways of accommodating zooming with a different UX. Though I'm not sure what the best approach is.

What you could do, is maybe give the option between the two methods.
N-Track does it.if I may suggest, and Enable button to switch between the two modes.so everybody is happy 😂😂

blueveek

@Paa89 said:

@blueveek said:

@Paa89 said:

@blueveek said
I pondering on whether to allow configuring the vertical divisions opacity, or simply creating a white theme. Not sure which is better, I'm leaning slightly towards just implementing a white theme.

Anyone else have any preference here?

Hello there @blueveek the white theme would be perfect.
And aslo if possible, could you make some to zoom in and out like the way Cubasis piano roll works?
The current way you have is that the whole piano roll becomes small or big .
Would be nice to be able to zoom in sections.

Agreed, this is one of those features where some people love it, some people prefer it the "old" way.

Decoupling vertical/horizontal zooming is something that I've received requests for, but I'm seriously disliking the way pinch gestures currently work with other piano rolls on iOS. I think that having a single gesture for simultaneous independent horizontal and vertical zooming is fundamentally bad UX with touch screens, so I'm exploring different ways of accommodating zooming with a different UX. Though I'm not sure what the best approach is.

What you could do, is maybe give the option between the two methods.
N-Track does it.if I may suggest, and Enable button to switch between the two modes.so everybody is happy 😂😂

Yes, momentary toggles is what I'm currently experimenting with.

Bachus

Just a quick question..

Watched some youtube’s
Its indeed a powerfull tool..

But how does it handle automation of CC?

wim

@Bachus said:
Just a quick question..

Watched some youtube’s
Its indeed a powerfull tool..

But how does it handle automation of CC?

It doesn’t yet.

jonmoore

Outside of the world of piano rolls the most elegant UX solution I've encountered for interface elements that both scale horizontally and vertically is in the the world of 3d/moving image compositing timelines. The likes of Nuke and Houdini feature a 'locked momentary interaction'. If the user starts a horizontal zoom, the vertical zoom is disabled momentarily (until the mouse button is lifted), and the action is vice versa when the initial zoom interaction is vertical.

It's surprising how natural this interaction becomes in a very short space of time, and it's perfect for tablets as it doesn't involve any modifier keys. Other smart features are elegant auto zooming based upon selected events. The most simple of these is 'middle click to zoom extents' when no events are selected. But it gets really useful when you have a group of events selected. The middle click on this occasion auto zooms the timeline to fit all the selected events. This would obviously have to be adapted for tablet interaction but there's a multitude of ways to skin that proverbial cat.

reasOne

@wim said:

@slicetwo said:

@wim said:

@HydraGen said:
I'm using up to eight hardware synths per AUM project so I need to assign them to eight different midi channels and can't seem to find that setting...

I assume your hardware synths are sending on separate channels? If so, then open up the routing for each channel, and de-select the channels that you don’t want. Example below: filtering out all but channel 2.

I'm trying to control my Digitone with Atom in AUM. I have the DN set to channels 11-14 for receiving MIDI, but I can't figure out how to get Atom to SEND on channel 11. It seems your diagram sets up what Atom will receive as opposed to sending out. Any ideas on setting the output channel?

You can’t at this time. The only way to do it right now is to use something like mfxStrip to convert the midi to another channel. There are other apps that can do the channel conversion as well, that’s just one easy to use and inexpensive example.

I know it’s in the plans for Atom to support channels at some point.

@wim do you think mfxstrip will let me send atom over idam to ableton using just one channel ?

wim

I don’t see why not. It’s just altering the channel, nothing else.

blueveek

@reasOne You can also use MIDI Tools Clone & Filter to route to different channels. Modular FTW, but I agree sometimes modular can be too modular.

reasOne

@wim said:
I don’t see why not. It’s just altering the channel, nothing else.

@blueveek said:
@reasOne You can also use MIDI Tools Clone & Filter to route to different channels. Modular FTW, but I agree sometimes modular can be too modular.

Good looking out guys

_ki

@blueveek said:
@reasOne You can also use MIDI Tools Clone & Filter to route to different channels. Modular FTW, but I agree sometimes modular can be too modular.

In one of my setups, i use 16 Atom AUs playing patterns and need to use 15 additional, intermediate ‚change midi channel‘ AUs before routing all of them into their common destination which needs the pattern data on separate input channels. AUMs matrix looks quite interwoven.

If Atom had an output channel selector, that would save 15 AUs and 15 connections

blueveek

@_ki said:

@blueveek said:
@reasOne You can also use MIDI Tools Clone & Filter to route to different channels. Modular FTW, but I agree sometimes modular can be too modular.

In one of my setups, i use 16 Atom AUs playing patterns and need to use 15 additional, intermediate ‚change midi channel‘ AUs before routing all of them into their common destination which needs the pattern data on separate input channels. AUMs matrix looks quite interwoven.

If Atom had an output channel selector, that would save 15 AUs and 15 connections

I agree, this isn't very nice.

Bachus

@wim said:

@Bachus said:
Just a quick question..

Watched some youtube’s
Its indeed a powerfull tool..

But how does it handle automation of CC?

It doesn’t yet.

yet, as in will be added sooner or later...
I guess this is an important feature for me...
As it could be a perfect way to create style tracks...

slicetwo

This may be to deep to implement, but I would love CC automation within Atom similar to how BM3 implements it in their piano roll. Then you could do almost stepped parameter locks like on the Elektron devices. Are there any AU step sequencers that can do this?

auxmux

@slicetwo Check out StepBud for p-lock style CC stepping.

For Atom, I'm hoping for something smoother like automation curve design capabilities in Ableton 10.1.

blueveek

@slicetwo said:
This may be to deep to implement, but I would love CC automation within Atom similar to how BM3 implements it in their piano roll. Then you could do almost stepped parameter locks like on the Elektron devices. Are there any AU step sequencers that can do this?

Working hard on it!

slicetwo

@blueveek said:

@slicetwo said:
This may be to deep to implement, but I would love CC automation within Atom similar to how BM3 implements it in their piano roll. Then you could do almost stepped parameter locks like on the Elektron devices. Are there any AU step sequencers that can do this?

Working hard on it!

That's cause you're friggin' badass. Haha. So glad you're trying to make this thing deeper.

audio_DT

@slicetwo said:

@blueveek said:

@slicetwo said:
This may be to deep to implement, but I would love CC automation within Atom similar to how BM3 implements it in their piano roll. Then you could do almost stepped parameter locks like on the Elektron devices. Are there any AU step sequencers that can do this?

Working hard on it!

That's cause you're friggin' badass. Haha. So glad you're trying to make this thing deeper.

This will make Atom one of the best things on iOS. 👌

david_2017

Talking about elektron.... any information regarding probability trigs or trig condition in future updates? I would really love to see these...
(Maybe there is content in the last 14 pages I haven’t seen or missed?!?)

blueveek

@david_2017 said:
Talking about elektron.... any information regarding probability trigs or trig condition in future updates? I would really love to see these...
(Maybe there is content in the last 14 pages I haven’t seen or missed?!?)

Any reason why using something like Cality wouldn't work? Or are you referring about actually triggering a whole pattern non-deterministically?

wim

Probability trigs = probability of a note playing set per note.
Trig conditions are things like “play this note every 4th loop...” and the like.

At least that’s what they mean to me.

GR-16 nails this IMO.

Sygma

@wim said:
Probability trigs = probability of a note playing set per note.
Trig conditions are things like “play this note every 4th loop...” and the like.

At least that’s what they mean to me.

GR-16 nails this IMO.

Trig conditions are one of the best features of Elektron sequencers. It adds variety to grooves.
As you said, GR-16 has succeeded in implementing this feature, and Jim has explained everything in his manual (chapter 4.5) : https://www.jimaudio.pro/grooverider/grooverider_manual.pdf
Having this in Atom Piano Roll would be great !

gdog

@blueveek said:

@slicetwo said:
This may be to deep to implement, but I would love CC automation within Atom similar to how BM3

Working hard on it!

I really hope there’s a way of drawing smooth automations too with lines/curves.. 🎛👌🎧

lukesleepwalker

@wim said:
Probability trigs = probability of a note playing set per note.
Trig conditions are things like “play this note every 4th loop...” and the like.

At least that’s what they mean to me.

GR-16 nails this IMO.

Couldn't a mozaic script handle this for any app? Sixteen dials for sixteen step probabilities.

blueveek

@lukesleepwalker said:

@wim said:
Probability trigs = probability of a note playing set per note.
Trig conditions are things like “play this note every 4th loop...” and the like.

At least that’s what they mean to me.

GR-16 nails this IMO.

Couldn't a mozaic script handle this for any app? Sixteen dials for sixteen step probabilities.

That's what I'm thinking as well. It seems like the current modular ecosystem in iOS allows this to happen easily. Just slap a Cality or Mozaic after Atom and get all the randomness you want!

bleep

Also, the trig conditions that are based on previous values (PREV in GR-16 doc) sound more fitting to step sequencers than a piano roll.

Btw, @blueveek, is it in your future plans to have a "step sequencer" option in Atom, or would you like to keep it strictly as a piano roll?

RajahP

@lukesleepwalker said:

@wim said:
Probability trigs = probability of a note playing set per note.
Trig conditions are things like “play this note every 4th loop...” and the like.

At least that’s what they mean to me.

GR-16 nails this IMO.

Couldn't a mozaic script handle this for any app? Sixteen dials for sixteen step probabilities.

Did not get Mozaic as yet... but how will it handle ‘probability’ on a per note basis?

lukesleepwalker

@RajahP said:

@lukesleepwalker said:

@wim said:
Probability trigs = probability of a note playing set per note.
Trig conditions are things like “play this note every 4th loop...” and the like.

At least that’s what they mean to me.

GR-16 nails this IMO.

Couldn't a mozaic script handle this for any app? Sixteen dials for sixteen step probabilities.

Did not get Mozaic as yet... but how will it handle ‘probability’ on a per note basis?

It wouldn't. The probability would be by step in the sequence. Mozaic would be agnostic of the actual note played. Admittedly, would be pretty crude relative to what you could do in a piano roll but, jeepers, setting probability per note in a complex piano roll sequence has got to be an edge case for most apps.

blueveek

@lukesleepwalker said:

@RajahP said:

@lukesleepwalker said:

@wim said:
Probability trigs = probability of a note playing set per note.
Trig conditions are things like “play this note every 4th loop...” and the like.

At least that’s what they mean to me.

GR-16 nails this IMO.

Couldn't a mozaic script handle this for any app? Sixteen dials for sixteen step probabilities.

Did not get Mozaic as yet... but how will it handle ‘probability’ on a per note basis?

It wouldn't. The probability would be by step in the sequence. Mozaic would be agnostic of the actual note played. Admittedly, would be pretty crude relative to what you could do in a piano roll but, jeepers, setting probability per note in a complex piano roll sequence has got to be an edge case for most apps.

What I'm suggesting is having Mozaic listen to the notes sent by Atom, and mutate or gate them based on various probabilities. This seems doable to me, maybe @brambos can confirm?

I would prefer to delegate this functionality to specialised apps, and just embrace modularity here. But I'm open to having my mind changed.

cian

@lukesleepwalker said:

@RajahP said:

@lukesleepwalker said:

@wim said:
Probability trigs = probability of a note playing set per note.
Trig conditions are things like “play this note every 4th loop...” and the like.

At least that’s what they mean to me.

GR-16 nails this IMO.

Couldn't a mozaic script handle this for any app? Sixteen dials for sixteen step probabilities.

Did not get Mozaic as yet... but how will it handle ‘probability’ on a per note basis?

It wouldn't. The probability would be by step in the sequence. Mozaic would be agnostic of the actual note played. Admittedly, would be pretty crude relative to what you could do in a piano roll but, jeepers, setting probability per note in a complex piano roll sequence has got to be an edge case for most apps.

You could do probability per beat (e.g. 75% for the 7th 16th note) relatively easily.