You are here

New MIDI bug - Notes on beat 1

I'd post to github but am not sure I have enough helpful information beyond my user experience. If logs and/or clips are needed, let me know and I'll supply.

As far as I can tell, the bug may have been introduced in 0.9.29.35 as that was the first occurrence. I was hoping my upgrade to 0.9.26.36 (via apt upgrade) would resolve it. No such luck.

How to reproduce:

In any Clip Editor view (Piano Roll), draw a MIDI note onto the very first beat of the clip. The following statements are now true:

1. The note can not be selected with the mouse.
2. The note's velocity can not be "grabbed" in order to raise or lower the value.
3. The note is not triggered when playback starts.
4. The note is viewable and can be modified in Event VIewer though these actions do not resolve the prior issues listed above.

While testing various scenarios, I noticed this quirky behavior seems to only occur with notes drawn on or moved to the first beat of a the clip. In other words, I can open a new clip, draw a note anywhere other than the first beat and everything is fine. If I move the note to the first beat, this scenario reveals itself.

Forums: 
rncbc's picture

hi, thanks for the report, I'll investigate on this later today

meanwhile, can you tell whether the issue is reproducible to any MIDI clip no mater where it's located or just happens to clips located at very beginning of the timeline (zero time; BBT=1.1.000) ?

seeya

It's definitely reproduced in any clip.

rncbc's picture

thanks,
i'll try to reproduce myself and get back to you ASAP.
brb
UPDATE: oops, can't reproduce it on 0.9.29.36git.c788cd :( all events at 1.1.000 seem to be selectable and movable in the MIDI clip editor alright here... there must be something else you're not telling me :)
maybe you may just create one MIDI clip where the issue is obvious to you and then share either the session or just the SMF (.mid), perhaps?

anyone else who is already doing the latest snapshot from git (as above) may chime in with same scenario? much appreciated.
cheers

Just to be clear, I didn't say it was limited to occur at (only) 1.1.000. Regardless, I can't seem to duplicate the bug on new sessions so it's obviously something tied specifically to the project I'm working on. I'm going to mess around a bit more on my end as I'd prefer to not share the data itself at this point. Even if I fork the session and strip things down to where I can reproduce it, that's not going to help you as it would be a complete change to the "environment" and you wouldn't know where the bug was actually introduced.

All the best

Hello again.

OK so I've put together the slimmest possible version of a project file I can which still shows the problem discussed. Basically, I made a copy of my original project and stripped out all the MIDI information. All that's left is the mixer settings. Even with this "shell" of a project, I think you'll see the behavior we've been discussing. This means the "bug", as I'm calling it, is not a result of MIDI data itself since there is no actual MIDI data associated with this project. Obviously the next step for me in terms of troubleshooting would be to remove plugins from the mixer strips 1 by 1 and see if the behavior changes. I don't have the time for that ATM so figured I'd send this .qtr file your way. Again, I don't believe this shows up when I create a new project so this is very curious.

OMG, LOL....... do I really have to trick this forum by renaming my file? ROTFMAO

File attachments: 
rncbc's picture

re. do I really have to trick this forum by renaming my file?
yes but you could upload a .qtz version of the file; plain text/xml .qtr are not allowed, sorry--the allowed upload file types/suffixes/extensions are listed there below;)

re. slimmest possible version of a project file
thanks, didn't test with this file, yet, but I suspect it might be related to the extreme low zoom-level (ie. minimum 10%) ?

UPDATE: issue confirmed; funny enough it happens only on some far-away locations (far from absolute time zero) but not all : if you create a clip on even farther locations the issue doesn't seem to occur... weird :S
rest assured GA release v0.9.29 does not suffer from this, or so I think :)
cheers

Yes! I believe I noticed the exact same thing in terms of where the condition would occur. I was testing a bunch of scenarios but didn't zero in on that for one reason or another. In any case, maybe I'll downgrade for the time being. I appreciate you taking the time to look at this.

Ran into a blocker trying to compile 0.9.29
https://github.com/rncbc/qtractor/issues/358#issuecomment-1316370063

You wouldn't happen to have that .deb sitting around would you? or know the fix to the above? Hoping to get past this issue by tomorrow night as I've got studio time booked for the weekend which I'm trying to prepare for.

All the best

rncbc's picture

maybe fixed on qtractor >= 0.9.29.37git.ae5dde

thanks

Thank you very much. I will test this tonight and report back :)

Fix confirmed! Thank you again.

Add new comment