Print

[ailton]

Hi

When I record while playing a pattern, my notes often happen to be placed a row too early. Is there a feature to clean this up automatically, i.e. move the notes to rows dividable by 4 for example?

Best regards
Ailton

[pailes]

Sorry but such a feature doesn't exist. The realtime recording is meant to record human timing misbehavior.

[raina]

No, there's not really. You can try enabling "Rec. note delays" in the config if you didn't already to make the quantization less coarse but that's about it. An opposite route would be to Shrink patterns and raise the Spd value so you'd have the song playing at the same speed but with only 50% or 25% the rows compared to the original and afterwards blowing up the patterns again. But obviously it won't work well with patterns that already have stuff on them, not without considerable amount of hassle at least, because notes get dumped by the Shrink function.

[ailton]

Ok, I see. Thanks for your quick replies.

I wonder why the notes are misplaced so often at all. I guess that the note is placed in the current row, no matter how close I am to the next row. Is this right?

Isn't it possible to snap the note to the closest row instead of snapping it to current row?  For example, if there are 6 ticks per row and I press a key at tick 6, it would be desirable (in my opinion) that the note is inserted in the following row.

I might err, but I think when I played around with Protracker on the Amiga (many years ago...) it worked that way.

[pailes]

I wonder why the notes are misplaced so often at all. I guess that the note is placed in the current row, no matter how close I am to the next row. Is this right?

Yes that's right. Well at least you can try to enable the "Note Delay recording" as raina already suggested, but you also need to select some low latency audio driver for this option.

Isn't it possible to snap the note to the closest row instead of snapping it to current row?  For example, if there are 6 ticks per row and I press a key at tick 6, it would be desirable (in my opinion) that the note is inserted in the following row.

Not now sorry, it requires too much of a logic change.

Only few people have actually been recording stuff so far, most composers tend to actually track their songs as the word tracker suggests

[ailton]

Yes that's right. Well at least you can try to enable the "Note Delay recording" as raina already suggested, but you also need to select some low latency audio driver for this option.

I have "note delay recording" enabled and I use the low latency ASIO4ALL driver. I already did so before my first post, but I like it "clean" without human delay information in the track, so I turned it off again.

Only few people have actually been recording stuff so far, most composers tend to actually track their songs as the word tracker suggests

Well, I have to admit that realtime recording isn't essential. I just like to improvise to the current state of a pattern... and when something nice comes up it is quicker to repeat and record it instead of tracking it. Sometimes I become obsessed of an idea of how things have to be done 

Anyway, I like MilkyTracker very much and it is the tracker of my choice after a long tracker-break! I can absolutely live with tracking instead of recording.

[pailes]

Well, I have to admit that realtime recording isn't essential. I just like to improvise to the current state of a pattern... and when something nice comes up it is quicker to repeat and record it instead of tracking it. Sometimes I become obsessed of an idea of how things have to be done 

I see. Now I'm wondering if an automated post-processing after recording would be a better approach to your problem as suggested in the subject/original post than filling in the data to the next closest row.

Anyway, I like MilkyTracker very much and it is the tracker of my choice after a long tracker-break! I can absolutely live with tracking instead of recording.

Nice to hear that.

[ailton]

I see. Now I'm wondering if an automated post-processing after recording would be a better approach to your problem as suggested in the subject/original post than filling in the data to the next closest row.

Hm... after thinking about it, I would prefer the "next-closest-row" approach.

Automated post-processing like quantization would be very nice too, but now I could imagine that its handling could be a little cumbersome. If there are passages that are really meant to be faster than the quantization parameter, these passages would have to be ignored by the quantization process (setting the quantization parameter to one row would obviously not help). Since it is impossible to automatically detect whether a short time intervall between two notes is intended or by accident, you would have to manually select rows to quantisize. What do you think?

With the "next-closest-row" approach, I think most notes would be placed in the correct row in the first place. Those which are not could be corrected manually. Ok, there is some manual work in both approaches but I guess correcting single notes is easier than finding areas to quantisize with a specific parameter.