Skip to content
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

Closed
sjaehn opened this issue Jun 7, 2020 · 11 comments
Closed

Fitting MIDI signals to steps #1

sjaehn opened this issue Jun 7, 2020 · 11 comments

Comments

@sjaehn
Copy link
Owner

sjaehn commented Jun 7, 2020

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.

@sjaehn
Copy link
Owner Author

sjaehn commented Jun 9, 2020

Step mapping solved in c2eec87.
TODO: MIDI signal positioning (classic quantization).

@magnetophon
Copy link

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.
When I add some 32nd notes to my input midi, I figured those would get quantized when Range is set to 0.50. They don't seem to move, other then the moving by the older functionality of the plugin.

"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.
Would you like a simple Ardour 5 session to demonstrate the issue?

@sjaehn
Copy link
Owner Author

sjaehn commented Jun 10, 2020

The new "smart quantization" contains two features.

  1. Handling of signals (including midi notes) on the edge of a step (just stepped). This is relevant as midi signals are not fully synchronized with the bar/beat information provided by the host. In theory (and I observed it) such a signal on the edge can be assigned to the starting step or to the step before. Assignment (or mapping) means it would get the amp of the just starting step or the amp before.

  2. This is what we usually understand with "quantization". Re-positioning of notes to a pattern. But this feature is not supported yet and will follow within the next days.

Range, I thought, would quantise notes if they are not too far off the grid, with range being the amount that defines "too far".

You are right.

I cannot get it to change anything though.

You can't classically quantize yet as this is still TODO. But you can get rid of the wrong step amp problem.

When I add some 32nd notes to my input midi, I figured those would get quantized when Range is set to 0.50. They don't seem to move, other then the moving by the older functionality of the plugin.

I tried the same but in my case I got the expected result.

"Step mapping" and "Signal positioning" I don't get at all. sorry.

I thought about a better description, but no idea. Maybe you know.

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.
Would you like a simple Ardour 5 session to demonstrate the issue?

Yes :-)

@magnetophon
Copy link

I don't understand your point 1., could you explain some more?
Could you also explain "Step mapping" and "Signal positioning" some more?

Sorry if I'm being dense...

In this session, play the loop:
SchafflDemo.zip

The 3rd repetition sounds different from the others.
Sometimes the 3rd is the same, but the 4th is different.

@sjaehn
Copy link
Owner Author

sjaehn commented Jun 10, 2020

Let me visualize the problem:

sq

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:

BSchaffl.lv2 @ 0,0000000000: Schedule MIDI signal 144 (60,33) to 0,0000000000
BSchaffl.lv2 @ 0,0625121527: Schedule MIDI signal 128 (60,33) to 0,0625121527
BSchaffl.lv2 @ 0,0625121527: Schedule MIDI signal 144 (64,64) to 0,0625121527
BSchaffl.lv2 @ 0,1249895819: Schedule MIDI signal 128 (64,64) to 0,1249895819
BSchaffl.lv2 @ 0,1249895819: Schedule MIDI signal 144 (67,35) to 0,1249895819

In the figure above the MIDI note started just before the start of step 2. There are at least three different consequences:

  1. Not handled. The plugin associates (or "maps") the note with the step 1 as the note started in step 1. This means that that the note input velocity is multiplied with the low amp of the step 1.
  2. "Mapping". Assuming that the note started within the range of the start of step 2, the note will be mapped to step 2. This means that that the note input velocity is multiplied with the high amp of step 2. But the note itself will not be moved rightwards. (At a later step during processing the str time shift the note may be shifted anyway but this will have no consequences for mapping.)
  3. "Positioning". Aka classic quantization. The note will be shifted rightwards and will exactly fit into step 2. It's worth to think about if the note should be mapped automatically (to step 2) or not.

@magnetophon
Copy link

Thanks, I get it now.
Maybe worth putting some of that text in various tool-tips.

For some practical reasons you will always get a deviation.

I thought jack midi was sample-accurate?
Is this issue related to the Ardour time representation thing?

Can you reproduce the issue with repetitions not sounding the same in that session?

@sjaehn
Copy link
Owner Author

sjaehn commented Jun 10, 2020

I thought jack midi was sample-accurate?

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.

@sjaehn
Copy link
Owner Author

sjaehn commented Jun 10, 2020

Can you reproduce the issue with repetitions not sounding the same in that session?

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.

@magnetophon
Copy link

@sjaehn Thanks for the explanation.

@x42: any idea why #1 (comment) happens?

@sjaehn
Copy link
Owner Author

sjaehn commented Jun 10, 2020

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:
BSchaffl.lv2 @ 4,9999376589: Schedule MIDI signal 144 (83,19) to 5,0111168460

Also note 2 starts to early (and is therefore amplified with the high value of step 1:
BSchaffl.lv2 @ 5,0624376589: Schedule MIDI signal 144 (83,64) to 5,0832322338

...

Different situation in bar 6 (and sound differently). Note starts behind the edge and therefore gets the right amplification for step 1:
BSchaffl.lv2 @ 6,0000471293: Schedule MIDI signal 144 (83,64) to 6,0112431634

Note 2 drops into step 1 again (as in bar 5):
BSchaffl.lv2 @ 6,0624688772: Schedule MIDI signal 144 (83,64) to 6,0832682539

...

@sjaehn
Copy link
Owner Author

sjaehn commented Jun 11, 2020

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 ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants