Activity for Matthias S. Benkmann
-
Matthias S. Benkmann posted a comment on ticket #282
The technical side is not the issue. The important thing is that you're not opposed to the concept. If you said that you oppose the change from duration to explicit note offs in principle, I wouldn't start working on it.
-
I might find the time to approach this over the Christmas holidays. But I wouldn't work on this if I had to maintain an independent fork, only if you'd accept the changes into your branch.
-
I can't stop thinking about this. I believe we can make Qtractor unambiguously better even within the confines of SMF and ticks, by leaning into SMF even harder. After all, the problem is that Qtractor internally deviates from SMF in a very important way. By dropping the Note OFFs. Not only does this cause my problem with legato, it also loses the Note Off velocity, which can be used by synthesizers like Surge XT. So how about fixing that. This is how I would go about it: Remove m_u.duration from...
-
If you want to expand your horizon into wind controllers, the most affordable option is probably the WARBL: https://www.warbl.xyz/ It's even open source, so you can see exactly where the "problem" comes from: https://github.com/amowry/warbl/blob/6a9260a04528ded1751d827591833afd28c45020/warbl_firmware/functions.ino#L1092 I don't want to imply that this is a WARBL-only issue. I fully expect the big guys from Yamaha and co to handle this the same way. I do hope that maybe one day under the shower you'll...
-
If you want to expand your horizon into wind controllers, the most affordable option is probably the WARBL: https://www.warbl.xyz/ It's even open source, so you can see exactly where the "problem" comes from: https://github.com/amowry/warbl/blob/6a9260a04528ded1751d827591833afd28c45020/warbl_firmware/functions.ino#L1092 I don't want to imply that this is a WARBL-only issue. I fully expect the big guys from Yamaha and co to handle this the same way.
-
Is the fix supposed to work with imported clips? Because I just tested it with the test.mid attached further above and it doesn't work. I don't think a fix that only affects recordings made directly in Qtractor is worth it. Can you explain your thought process why you are so resistant to changing Qtractor's internal precision? Maybe I haven't made clear enought what I'm thinking about, so let me elaborate a bit more how I would go about fixing this issue: Change all fields and variables that currently...
-
Is the fix supposed to work with imported clips? Because I just tested it with the test.mid attached further above and it doesn't work. I don't think a fix that only affects recordings made directly in Qtractor is worth it. Can you explain your thought process why you are so resistant to changing Qtractor's internal precision? Maybe I haven't made clear enought what I'm thinking about, so let me elaborate a bit more how I would go about fixing this issue: Change all fields and variables that currently...
-
I'm sick ATM. I'll try it when I get better.
-
You are ignoring that problem.mid was created by qtractor. It's not the input from the instrument. That's the core of the problem. Qtractor does not accurately record MIDI input (or import MIDI files accurately). Take the attached test.mid. I have a MIDIBus1 in Qtractor that appears in the list of aplaymidi -l as 130:0. If I play test.mid via aplaymidi -p 130:0 /tmp/test.mid the result is correct. Relevant output from aseqdump -p 130:0 7498:956017019 Pitch bend 0, value 648 7498:957017118 Pitch bend...
-
You are ignoring that problem.mid was created by qtractor. It's not the input from the instrument. That's the core of the problem. Qtractor does not accurately record MIDI input (or import MIDI files accurately). Take the attached test.mid. I have a MIDIBus1 in Qtractor that appears in the list of aplaymidi -l as 130:0. If I play test.mid via aplaymidi -p 130:0 /tmp/test.mid the result is correct. Relevant output from aseqdump -p 130:0 7498:956017019 Pitch bend 0, value 648 7498:957017118 Pitch bend...
-
Sorry for always coming back to the issue of precision, but as I understand it if I could raise BPM and ticks/beat high enough the problem would go away. Is it an ALSA limitation that these can't go above 1000 and 3840? If I could raise them so high that 1 tick would be less than 10 microseconds, then it would be enough resolution for note on and off to never fall on the same tick.
-
What about my suggestion from the very beginning to have a per-track setting that every time the end of one note and the beginning of another are on the same tick, always emit the note on for the new note before the note off of the previous note. That would be robust against manual editing and would not require any changes to the recording, just the re-generation of note on/note off on replay.
-
Here is the cut out clip of the 2 notes. You should be able to inport the mid into a MIDI clip and when playing it it should give the 80,81,81,80 pattern I describe above instead of the 80,81,80,81 pattern it should be.
-
It also doesn't seem to occur when I have aseqdump running at the same time. So it seems to be some race condition. I'm seeing small notes with duration less than 1ms (see attached image) in the recording. I am 99.9% certain that these are not coming in from my instrument although without the ability to run aseqdump simultaneously I can't prove it. I guess I could hook up my logic probe to the USB bus to observe without affecting system timing, but I don't feel like doing that right now :-) I assume...
-
Observation: It doesn't seem to happen if I record an Audio track at the same time. I tried to record both MIDI and Audio simultaneously to have the difference between the live performance and the replay but it never happened while I was trying that way. The moment I stopped recording the Audio track at the same time I got the problem again.
-
I'm trying it out currently. It seems to work most of the time but I've had occasional cases where a note would not turn off at the end of the track and once it sounded like the note off of a non-overlapping note was delayed till the next note despite the notes being separate. I'm trying around to find something reproducible.
-
I don't have a build environment for qtractor. You'd have to give me an .AppImage
-
I just added timestamps to aseqdump and I am happy to report that if using realtime timestamping the note off and note on events do have different timestamps. They are about 10 microseconds apart, which is in the expected range. So I'l get back to my statement that you don't need any dirty hacks, you just need to use a higher time precision in qtractor. It doesn't matter that you convert to duration. If you stored the note duration and the note start in microseconds, then the notes in my case would...
-
I've only ever programmed with ALSA's raw MIDI input. As I look at the API now it seems that the higher level ALSA API has a timestamp with every event. Where does that come from and what is its resolution? MIDI input data from the MIDI controller does not have timestamps. It just arrives based on when the respective USB port is queried. If ALSA just gives every MIDI input that arrives in the same USB transaction the same timestamp, that would explain why events get quantized to 1ms. USB query frequency...
-
-
But the problem is that overlaps less than 1ms disappear. Otherwise there would be no problem. My input are 2 different notes that overlap 72 ----------------- ------------------------ 74 But the overlap time is just a few microseconds and any overlap time less than 1ms disappears in Qtractor. If I used a piano style controller I could also by chance have an overlap less than 1ms and the result would also be that what I hear while playing live is not the same as what I hear when replaying the "recording"...
-
But the problem is that overlaps less than 1ms disappear. Otherwise there would be no problem. My input are 2 different notes that overlap 72 ----------------- ------------------------ 74 But the overlap time is just a few microseconds and any overlap time less than 1ms disappears in Qtractor. If I used a piano style controller I could also by chance have an overlap less than 1ms and the result would also be that what I hear while playing live is not the same as what I hear when replying the "recording"...
-
But the problem is that overlaps less than 1ms disappear. Otherwise there would be no problem. My input are 2 different notes that overlap 72 ----------------- --------------------------- 74 But the overlap time is just a few microseconds and any overlap time less than 1ms disappears in Qtractor. If I used a piano style controller I could also by chance have an overlap less than 1ms and the result would also be that what I hear while playing live is not the same as what I hear when replying the "recording"...
-
Thinking about it, what do you do with sysex events? Does Qtractor mess up their ordering, too, if they arrive within the same 1ms window? That sounds like it could be a problem, too. The more I think about it, I think you should just increase your timestamp precision. You don't have to expose it to the user and when the user shifts around notes with the mouse there will always be quantization, but at least MIDI data from external sources would be accurately represented.
-
I think you're looking at it the wrong way. Legato play means that notes overlap. The note on for the next note comes before the note off for the previous note. That's true for every instrument. It's just that for a piano, because it has separate keys and because of the limitations of human hand motion the overlap will practically always be more than a few milliseconds. But a flute physically cannot produce 2 notes at the same time. If you open one hole the old note stops at the exact same time the...
-
I think you're looking at it the wrong way. Legato play means that notes overlap. The note on for the next note comes before the note off for the previous note. That's true for every instrument. It's just that for a piano, because it has separate keys and because of the limitations of human hand motion the overlap will practically always be more than a few milliseconds. But a flute physically cannot produce 2 notes at the same time. If you open one hole the old note stops at the exact same time the...
-
I think you're looking at it the wrong way. Legato play means that notes overlap. The note on for the next note comes before the note off for the previous note. That's true for every instrument. It's just that for a piano, because it has separate keys and because of the limitations of human hand motion the overlap will practially always be more than a few milliseconds. But a flute physically cannot produce 2 notes at the same time. If you open one hole the old note stops at the exact same time the...
-
Yes, the events in question do have the same timestamp, because the controller is a wind controller and naturally note off and note on happen simultaneously when a hole is covered/uncovered while the player blows one note ends and another note starts with no time in between. If QTractor does not store Note Off position in the MIDI data stream that is a serious limitation. This isn't just a pecularity of Surge XT. Fluidsynth too uses the ordering of note on and off to detect legato in particular with...
-
Qtractor destroys legato by reordering Note On and Note Off
-
New hardware option for i2c access
-
An example for this issue is here: https://jlcpcb.com/ Hover over "Resources", a navigation menu appears. Try to click "SMT Parts library". The navigation menu disappears but you don't go to the correct page. Instead what happens is you go to the page you would have gone to had you clicked the same spot on the screen without the nav menu open. Some relevant code from the page: <div class="subMenuBox over" onmouseover="changeNav(1)" onmouseleave="closeNav(1)" style="display: none;"> So apparently...
-
An example for this issue is here: https://jlcpcb.com/ Hover over "Resources", a navigation menu appears. Try to click "SMT Parts library". The navigation menu disappears but you don't go to the correct page. Instead what happens is you go to the page you would have gone to had you clicked the same spot on the screen without the nav menu open. Some relevant code from the page: <div class="subMenuBox over" onmouseover="changeNav(1)" onmouseleave="closeNav(1)" style="display: none;"> So apparently...
-
An example for this issue is here: https://jlcpcb.com/ Hover over "Resources", a navigation menu appears. Try to click "SMT Parts library". The navigation menu disappears but you don't go to the correct page. Instead what happens is you go to the page you would have gone to had you clicked the same spot on the screen without the nav menu open. Some relevant code from the page: So apparently the mouse leave event triggers the disappearing of the navigation menu. It looks like what is supposed to happen...
-
I'm just using *.go -autoindent -syntax go
-
First, the licenses are compatible. Second, you're not linking the file with GPL...
1