#132
- Created on2010-08-11 04:06
- Reported by
- StatusInvalid
- PriorityNormal (3)
- Assigned to-
- Milestone
- Plan Level-
- Due Date-
midi : midi binding conflict mutes midi instrument triggers
0.9.5rc on ubuntu 10.04 (in pattern mode)
steps to reproduce :
- connect a midi controller (i used the virtual vkeyb app to test) to the hydrogen midi input
- goto Extra-Settings-Midi and press the midi learn button
- now press a key on vkeybd that is also used to trigger an instrument (eg key 49>tom) and link it to the STOP action
- also using the midi learn, config a START midi key on a key that does NOT conflict with an instrument key (eg key 65)
- close dialog
- now press the 'PLAY' key on the vkeybd (key 65) > loop starts to play
- press the STOP key on vkeybd (key 49) > loop stops and the tom did not play > OK (apparently the midi messages are intercepted if they are linked to a user defined midi action)
- now swap the midi mappings for the START and STOP keys (in the midi dialog) : start is now linked to key 49, stop to key 65
- start the loop by pressing key 49 on vkeyb > loop starts
- hit key 65 and the loop stops > OK
- now hit key 49 (loop starts) and hit it again > no sound since the midi message is intercepted > ok
- the interesting part (finally ! ;-) : all other keys that are linked to an instrument (eg key 50) also dont trigger any sound any more ?? (press several 'instrument' keys to test)
- now hit key 65 (stop) > loop stops, but sometimes all the instruments that you presses a key for (in the previous step) seem to be triggered all at once !
> it seems like all these midi events have been placed in a cue, and the cue is 'emptied' upon a STOP command
the moment that the cue buffer is 'emptied' can also be at another time. it's always at the beginning of the loop, but seems to be unpredictable when exactly (i'm also using the SELECT_NEXT_PATTERN midi event and it seems to be linked with (de)activating a pattern (in stacked mode)
hope this all makes sense
grtz
thijs
steps to reproduce :
- connect a midi controller (i used the virtual vkeyb app to test) to the hydrogen midi input
- goto Extra-Settings-Midi and press the midi learn button
- now press a key on vkeybd that is also used to trigger an instrument (eg key 49>tom) and link it to the STOP action
- also using the midi learn, config a START midi key on a key that does NOT conflict with an instrument key (eg key 65)
- close dialog
- now press the 'PLAY' key on the vkeybd (key 65) > loop starts to play
- press the STOP key on vkeybd (key 49) > loop stops and the tom did not play > OK (apparently the midi messages are intercepted if they are linked to a user defined midi action)
- now swap the midi mappings for the START and STOP keys (in the midi dialog) : start is now linked to key 49, stop to key 65
- start the loop by pressing key 49 on vkeyb > loop starts
- hit key 65 and the loop stops > OK
- now hit key 49 (loop starts) and hit it again > no sound since the midi message is intercepted > ok
- the interesting part (finally ! ;-) : all other keys that are linked to an instrument (eg key 50) also dont trigger any sound any more ?? (press several 'instrument' keys to test)
- now hit key 65 (stop) > loop stops, but sometimes all the instruments that you presses a key for (in the previous step) seem to be triggered all at once !
> it seems like all these midi events have been placed in a cue, and the cue is 'emptied' upon a STOP command
the moment that the cue buffer is 'emptied' can also be at another time. it's always at the beginning of the loop, but seems to be unpredictable when exactly (i'm also using the SELECT_NEXT_PATTERN midi event and it seems to be linked with (de)activating a pattern (in stacked mode)
hope this all makes sense
grtz
thijs
Leave a comment
below is a quote from a mailing thread from 15sept about the release 0.9.4.2
there is also some info about this bug in this mailing (thanks Krzysztof !) that i wanted to add to this ticket :
On 09/16/2010 02:11 PM, Krzysztof Foltman wrote:
> I might try to take a look at it, I'm sometimes lucky when it comes to
> weird bugs. However, don't hold your breath - or the 0.9.4.2 release.
Looks like everything is fine up to addRealtimeNote, where things start
going seriously wrong. I'm too sleepy now to try to figure out what
exactly is going wrong, but I'm guessing that a new note is queued with
the wrong position (it is played, just not immediately, there's a
delay, sometimes very long). Also, there's this:
(E) Sampler __render_note Note pos in the future?? Current frames:
504640, note frame pos: 565823
(E) Sampler __render_note Note pos in the future?? Current frames:
504640, note frame pos: 574693
(E) Sampler __render_note Note pos in the future?? Current frames:
504640, note frame pos: 582297
Which also points at note scheduling as a potential problem.
Replacing realcolumn with 0 near line 1994 in
libs/hydrogen/src/hydrogen.cpp seems to hide the problem, forcing the
new note to be scheduled at earliest possible time, but I'm not sure how
safe it is. It also doesn't really fix the underlying problem, just
masks it. However, it looks like the underlying problem is complicated
(mixed up time bases or something like that), so I'll try to investigate
it some other day.
The nested for loop about line 1934 is seriously puzzling, too, but it's
NOT a source of the problem, I think.
there is also some info about this bug in this mailing (thanks Krzysztof !) that i wanted to add to this ticket :
On 09/16/2010 02:11 PM, Krzysztof Foltman wrote:
> I might try to take a look at it, I'm sometimes lucky when it comes to
> weird bugs. However, don't hold your breath - or the 0.9.4.2 release.
Looks like everything is fine up to addRealtimeNote, where things start
going seriously wrong. I'm too sleepy now to try to figure out what
exactly is going wrong, but I'm guessing that a new note is queued with
the wrong position (it is played, just not immediately, there's a
delay, sometimes very long). Also, there's this:
(E) Sampler __render_note Note pos in the future?? Current frames:
504640, note frame pos: 565823
(E) Sampler __render_note Note pos in the future?? Current frames:
504640, note frame pos: 574693
(E) Sampler __render_note Note pos in the future?? Current frames:
504640, note frame pos: 582297
Which also points at note scheduling as a potential problem.
Replacing realcolumn with 0 near line 1994 in
libs/hydrogen/src/hydrogen.cpp seems to hide the problem, forcing the
new note to be scheduled at earliest possible time, but I'm not sure how
safe it is. It also doesn't really fix the underlying problem, just
masks it. However, it looks like the underlying problem is complicated
(mixed up time bases or something like that), so I'll try to investigate
it some other day.
The nested for loop about line 1934 is seriously puzzling, too, but it's
NOT a source of the problem, I think.