Topic: Preview 2.41: MIDI input quantization

This topic has 25 replies, 7 voices, and was last updated 13 years, 1 month ago by Zynewave.

Viewing 11 posts - 16 through 26 (of 26 total)

← 1 2

December 30, 2010 at 08:10 #20170

thcilnnahoj
Participant

@Zynewave wrote:

It would be stored per track, but it would not work as a track-wide automatic quantization. It would be used for setting up the note editor grid (much like how note map setup is done) and MIDI input recording. If changing the setting would automatically quantize all events, then it would be total mayhem.

Now I’m confused again. So it isn’t relevant to the arrangement editor snap setting but the note editor…? Meaning every time you open a sequence on the drum track, the editor’s snap value could be set differently than when editing a sequence on the piano or bass tracks?

December 30, 2010 at 14:03 #20175

Zynewave
Keymaster

@thcilnnahoj wrote:

Do you think it’s better to have quantization applied destructively (but still reversible – I speaks gooder English in the morning :wink:) in order to have the notes drawn at the timeline position they’re actually played? I don’t know if a playback-only implementation would be confusing, but I do like the way the current MIDI transpose and randomize options work.

After giving it some thought, I think it is better to have the quantization applied to the events, so that the events are displayed on the editor timeline as they are played. Otherwise it would cause a lot of confusion when editing events, if you are not wary about whether a track is being quantized.

As a consequence of applying quantization to the events, you cannot have different quantization settings applied to phantom copies of a sequence on different tracks.

December 30, 2010 at 14:44 #20176

Zynewave
Keymaster

@thcilnnahoj wrote:

@Zynewave wrote:

It would be stored per track, but it would not work as a track-wide automatic quantization. It would be used for setting up the note editor grid (much like how note map setup is done) and MIDI input recording. If changing the setting would automatically quantize all events, then it would be total mayhem.

Now I’m confused again. So it isn’t relevant to the arrangement editor snap setting but the note editor…? Meaning every time you open a sequence on the drum track, the editor’s snap value could be set differently than when editing a sequence on the piano or bass tracks?

Yes. There are pros and cons of that method. Often you would use different grid settings when editing drum sequences versus chord sequences, but on the other hand, you would need to set the appropriate grid setting every time you create a new track. The grid setting would work exactly like the current “note map” track properties. It’s probably a bad idea, but I just wanted to mention it as an alternative solution.

January 2, 2011 at 01:39 #20198

Zynewave
Keymaster

Ok. After working with this for a few days now, I’m thinking that a proper implementation of groove templates would be better than my previous input quantization suggestion. So, forget everything I suggested previously in this topic, and consider this new extended sequence properties dialog instead:

Previously only the sequence name was in that dialog. You can assign multiple sequences as groove templates. Once you have defined one or more groove template sequences in a project, the right-click or edit menu of sequence events will contain a new “Groove” submenu, with the list of available groove templates.

Making the groove templates assignable to sequence events rather than tracks, makes it possible to assign different grooves along the timeline.

If you edit the sequence groove properties or the notes in the groove sequence, it will affect the playback in real-time of all sequence events that are assigned with that groove template.

I think this solution would make it redundant, or at least reduce the need for a dedicated “destructive” input quantization. You would just assign a straight 16th note groove to a drum sequence you are recording, and your recorded notes will automatically play quantized on the next loop. Once you are done with the layering of drum notes, you could apply the quantize edit command, to tidy up the sequence.

Comments, suggestions?

January 2, 2011 at 09:58 #20204

LiquidProj3ct
Participant

Making the groove templates assignable to sequence events rather than tracks, makes it possible to assign different grooves along the timeline.

Could be possible have a track groove overwritted in real time with by secuences groove?

January 2, 2011 at 13:10 #20206

4mica
Participant

I like what I see so far…just wondering along the same lines as what LiquidProj3ct asked, if there will be track groove as well as sequence groove, if one can override the other. Good luck—

January 2, 2011 at 19:02 #20211

Zynewave
Keymaster

@LiquidProj3ct wrote:

Making the groove templates assignable to sequence events rather than tracks, makes it possible to assign different grooves along the timeline.

Could be possible have a track groove overwritted in real time with by secuences groove?

I’ll consider that. If a groove template is assigned to a sequence event, it would override any groove template assigned to the track.

I suppose a groove assigned to a track should be inherited by child tracks, agreed? This means that any parameter tracks will also be affected by the groove template on the parent track. This may not always be desirable, if you for example are using level automation to gate the audio synced to other tracks. So, perhaps the groove selector on the track should include the options “None”, “Use groove from parent track”, followed by the list of defined groove template sequences.

January 3, 2011 at 04:33 #20212

thcilnnahoj
Participant

@Zynewave wrote:

@LiquidProj3ct wrote:

Making the groove templates assignable to sequence events rather than tracks, makes it possible to assign different grooves along the timeline.

Could be possible have a track groove overwritted in real time with by secuences groove?

I’ll consider that. If a groove template is assigned to a sequence event, it would override any groove template assigned to the track.

I suppose a groove assigned to a track should be inherited by child tracks, agreed? This means that any parameter tracks will also be affected by the groove template on the parent track. This may not always be desirable, if you for example are using level automation to gate the audio synced to other tracks. So, perhaps the groove selector on the track should include the options “None”, “Use groove from parent track”, followed by the list of defined groove template sequences.

This sounds like a very good plan to me! 8)

I think this solution would make it redundant, or at least reduce the need for a dedicated “destructive” input quantization. You would just assign a straight 16th note groove to a drum sequence you are recording, and your recorded notes will automatically play quantized on the next loop. Once you are done with the layering of drum notes, you could apply the quantize edit command, to tidy up the sequence.

Comments, suggestions?

Wouldn’t that mean that you have to create a sequence before recording, or pause inputting notes after the first loop to set up a groove template for the sequence to have it auto-quantized? I don’t know how you do it, but I personally don’t create any sequences by hand when recording.
I guess this wouldn’t be an issue if there was a track-wide groove template as well, as suggested above.

As for suggestions… how about a “G” icon or some other indicator on sequence events that use a groove template – otherwise you’ll have a hard time remembering which ones you, uh, made groovy!

January 5, 2011 at 15:20 #20215

Zynewave
Keymaster

@thcilnnahoj wrote:

@Zynewave wrote:

@LiquidProj3ct wrote:

Making the groove templates assignable to sequence events rather than tracks, makes it possible to assign different grooves along the timeline.

Could be possible have a track groove overwritted in real time with by secuences groove?

I’ll consider that. If a groove template is assigned to a sequence event, it would override any groove template assigned to the track.

I suppose a groove assigned to a track should be inherited by child tracks, agreed? This means that any parameter tracks will also be affected by the groove template on the parent track. This may not always be desirable, if you for example are using level automation to gate the audio synced to other tracks. So, perhaps the groove selector on the track should include the options “None”, “Use groove from parent track”, followed by the list of defined groove template sequences.

This sounds like a very good plan to me! 8)

I think this solution would make it redundant, or at least reduce the need for a dedicated “destructive” input quantization. You would just assign a straight 16th note groove to a drum sequence you are recording, and your recorded notes will automatically play quantized on the next loop. Once you are done with the layering of drum notes, you could apply the quantize edit command, to tidy up the sequence.

Comments, suggestions?

Wouldn’t that mean that you have to create a sequence before recording, or pause inputting notes after the first loop to set up a groove template for the sequence to have it auto-quantized? I don’t know how you do it, but I personally don’t create any sequences by hand when recording.
I guess this wouldn’t be an issue if there was a track-wide groove template as well, as suggested above.

It would require a pre-created sequence event before a groove template can be assigned to it, so that is one reason why being able to assign groove templates to tracks is a good idea.

February 14, 2011 at 13:41 #20338

siegfried
Participant

@Infinitoar wrote:

ld it be for you to develop a MIDI Keyboard option in Podium?[EX: I hit “a, s, d, f, and notes play…] Because I don’t know the full spectrum on coding for Podium but I am just wondering…

+1 !!! This is great idea! No need for visual fancy keyboard, only that computer keyboard playing notes…. like in for example Renoise etc. Absolutely great feature!!!

March 25, 2011 at 23:05 #20514

Zynewave
Keymaster

2.41 is now released, but without the feature discussed in this topic. As mentioned in other topics, I did not have much time for Podium development during the last couple of months. I have now started developing again, but the first few releases will just contain minor stuff and bug fixes. Eventually I’ll get back in the groove. 😉

Viewing 11 posts - 16 through 26 (of 26 total)

← 1 2

You must be logged in to reply to this topic.