Topic: Preview 2.31: Slide/zoom key shortcuts

@Zynewave wrote:

Most drum plugin editors have mute/solo buttons in their UI, but I assume it’s more convenient to have the buttons close at hand when working with the pattern in the drum map editor. Is convenience the primary reason for you to have mute/solo in the drum map editor?

Yes, it’s faster than open the plugin gui and very very very comfortable.

Besides having mute/solo as a way of auditioning elements in a drum loop, would you use the mute/solo states as a fixed part in the final loop? In other words, would you leave some notes soloed/muted once you’re done working on the loop?

Yes, I could need change it later. i never know when I’m going to need do a change until I finish the song, having those drums muted allow me “save” small ideas to quick recall them (unless while podium doesn’t support something like a pattern poll)

@Zynewave wrote:

@Conquistador wrote:

@Zynewave wrote:

Ok, then the mute/solo state are properties of the note sequence object. Is this preferrable over having them properties of the track? And why?

Not sure what you mean here sorry. I don’t want to choose between the functionality of the track mute / solo over the drum lane mute / solo can they not co – exist in Podium? With track Mute overriding drum lane mute if need be ❓ ❓ ❓

When I say they are properties of the track, then I mean they are just stored as hidden properties of the track object instead of the sequence object. They don’t interfere with normal track solo/mute. The difference is that when the drum map editor stores the note solo/mute states as track properties, then all sequences placed on that track will adopt the same solo/mute state. Like LiquidProj3ct, I prefer this behaviour.

That’s how I imagined it would work.

@Zynewave wrote:

A muted track will of course mute any soloed drum notes on that track.

Ok on the same page…

When you emphasized “within a drum MIDI event” I thought you suggested that the solo/mute should be local to only that clip, and other clips on the same track should not be affected. From your latest comments, I take it you didn’t mean that.

Nooooooo. So that is where the confusion started. That was simply an example with one MIDI event. No more no less. Thats all. 🙂

We are definitely on the same page. 8)

@Zynewave wrote:

@LiquidProj3ct wrote:

– End to center vertically on the current selection.

Could it be automatic each time you open a piano roll /drum roll editor please?

I’ve changed it so that it will center automatically when opening the editor, but not when changing the sequence while the editor remains open. Automatic centering would simply be too confusing, if you for example Alt+Click a ghost note to change sequence.

I think it would be best to include a “follow/center events” (or something) option in the editors’ view menus. Centering the view the first time only isn’t quite as useful, and if you dislike it, you could just turn it off.

@Zynewave wrote:

@thcilnnahoj wrote:

Does it not bother you that the mouse cursor changes to the vertical zoom cursor, when you hold down Ctrl+Shift for transposing octaves?

That never bothered me. I won’t be standing in the way if you want to change it, just want to say again that Ctrl (moving notes) together with Shift made sense to me, while Alt doesn’t really fit. I don’t have any alternatives to offer, either. 😐

I need to check the code for conflicts with other key shortcuts, but how about Shift+Up/Down instead of Alt+Up/Down for transposing octaves?

Is still feels a little detatched since shift isn’t used for any moving action, but I like it better. I was thinking right now that I kind of would expect Shift+Arrows to extend the selection of notes in whichever direction, hm.
You can still switch it to alt, it’s just one guy’s opinion after all. 😉

I don’t have the need of see the true lenght of the event. What I’d like is treat drum roll events as piano roll events, where you can adjust their lenght. It isn’t too important though, but it’s good for consistency.

@Zynewave wrote:

Oh no!, I’m going to be flooded with bug reports the coming days! 😉

You better put some more in the next beta then, because so far I’ve only got one candidate! 😛

There’s a problem selecting notes with a selection rectangle – they are only selected when the rectangle includes the very first pixel at the note start, regardless of actual or displayed note length.

– Why are the “keys” arranged bottom to top compared to the piano roll?

You know, it made sense years ago when I implemented it :-k . I guess I was thinking that the most prominent drums (kick, snare, etc.) should be at the top when you first open the editor. If I implement a feature to hide unused drum lines, I think it’s ok to swap them around so low notes are at the bottom. If anyone objects to this, please post why.

It probably does make more sense, but all the General MIDI and custom drum maps I’ve seen are arranged the other way around. It’s already weird if the notes reverse when going from the note to the drum editor.

Addictive Drums also lets you re-map everything, and I assume it then passes the key names on to the host, if that’s what you mean by custom drum key names.

Besides hiding unused keys, another feature dream would be being able to rearrange and rename the keys, and save them as a sort of drum map template.
I would also welcome an option for auditioning selected and edited notes, like in the piano roll. It’s the first thing I turn off there. 😉

@Zynewave wrote:

– The grid/snap value seems to adjust all notes’ visual length – huh? A 1/16 note looks like a 1/4 note if you select that grid setting.
I don’t know how other sequencers’ drum maps work, but for me it’s important to be able to set note lenght (and see it). For example, Poise has a “note on” mode, in which a sample pad is triggered only as long as the note is held.

All events are displayed with a minimum size of the grid value. There’s a historic reason for this: Years ago many MIDI drum files had very short note durations, because drum machines back then usually only needed a trigger note to play the entire drum sound. So if those ancient MIDI drum files should be displayed with true durations, you would only see very thin drum notes that would be difficult to click and edit.

Maybe this need to be updated as well. Instead of using the grid value as the minimum duration, it is perhaps better to have a minimum pixel width setting, and a way to display that the true length of the event is perhaps shorter than the clickable event. Suggestions are welcome.

A few random suggestions (from “meh.” to “not much better either” :wink:)

– If the drum notes in those MIDI files are really that short, I would assume it’s safe to destructively adjust their length to at least a 128th note on import, without messing up very quick runs on other instruments (personally, I’ve yet to see someone produce notes that short)?
However, if you wanted to export the drums MIDI again, it would of course be different – may be no problem as long as it’s still compatible with drum machines and other sequencers.

– If that sounds bad, maybe just use 128th as minimum display size, and leave the notes as they are otherwise. Some selection/resize things have to be fixed for this to work, though.

– One indication that a note is shorter than it looks could be sawing it off at the end, the way markers look. However, the notes would probably have to be drawn at full height for this to be clear, and just the color shading used to display velocity.

– Disable any adjustment options and reflection of note length in the drum editor completely, and just use, e.g., fixed 32th blocks, like other sequencers use those diamond shapes. Users that do need to adjust note lengths could switch over to the note editor for this.