-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fitting MIDI signals to steps #1
Comments
Step mapping solved in c2eec87. |
I don't understand what the new parameters do. Range, I thought, would quantise notes if they are not too far off the grid, with range being the amount that defines "too far". I cannot get it to change anything though. "Step mapping" and "Signal positioning" I don't get at all. sorry. Also: not all the algo bugs seem to be fixed: When I input a fixed looping pattern, the first few repetitions sound different from the later. |
The new "smart quantization" contains two features.
You are right.
You can't classically quantize yet as this is still TODO. But you can get rid of the wrong step amp problem.
I tried the same but in my case I got the expected result.
I thought about a better description, but no idea. Maybe you know.
Yes :-) |
I don't understand your point Sorry if I'm being dense... In this session, play the loop: The 3rd repetition sounds different from the others. |
Let me visualize the problem: This figure shows a midi note coming sent from the host to the plugin. In theory the note should exactly fill step 3. For some practical reasons you will always get a deviation. In case of the default 1/16 pattern, each step should be 1/16 = 0.0625. In this dump you can see that note 2 starts a bit too late, but note 3 starts a bit too early:
In the figure above the MIDI note started just before the start of step 2. There are at least three different consequences:
|
Thanks, I get it now.
I thought jack midi was sample-accurate? Can you reproduce the issue with repetitions not sounding the same in that session? |
Right, MIDI is associated with a sample and therefore it should be sample-accurate. But stepping (from step 1 to step 2) isn't. Position information (bar/beat) are floating point and sample numbers are integers. Based on this information the deviation should be less than one sample anyway. But if I use the dump data, I calculate a deviation of a lot more samples. I don't have any idea why. |
I can hear it. I'll investigate the dump. Edit: I played around. All bars sound the same way if I switch on mapping and set range to some 0.12. Therefore, I think it is related to the step edge problem too. |
@sjaehn Thanks for the explanation. @x42: any idea why #1 (comment) happens? |
As I expected. It is the edge problem. Note 1 in bar 5 (and the most of the other bars) starts a bit too early and is therefore amplified with the low value of step 11: Also note 2 starts to early (and is therefore amplified with the high value of step 1: ... Different situation in bar 6 (and sound differently). Note starts behind the edge and therefore gets the right amplification for step 1: Note 2 drops into step 1 again (as in bar 5): ... |
FYI, "positioning" (quantization in narrow sense) is now implemented in 1cf9f8b . Toggle both (mapping + positioning) to get full quantization behavior as you would expect. Just thinking about renaming the features ... |
Tricky part (and TODO): Incoming MIDI signals are not 100% synchronous to host time/beat information. Therefore, a MIDI signal (e.g., NOTE_ON) that should start at the beginning of a step may appear at the end of the previous step. And a MIDI signal (e.g., NOTE_OFF) that should end at the end of a step may end at start of the next step.
By now, amplification is for a whole step. If a MIDI signal dropped into an incorrect step (as described above), it will be amplified with an incorrect value.
The text was updated successfully, but these errors were encountered: