Thread: [Qtractor-devel] More serious Pgm Change bug
An Audio/MIDI multi-track sequencer
Brought to you by:
rncbc
From: Ralf M. <ral...@al...> - 2015-04-03 10:31:36
|
Hi, I'm the composer, I'm the one who knows in what way external gear is connected and used, so for good reasons I decided to have a Pgm Change at time 2.1.000 in a clip from 1.1.000 to 11.1.000. How can I get rid of the Pgm Change that Qtractor automatically adds at time 1.1.000? If I delete the unwanted Pgm Change and/or select "Program: (None)", then save the .mid file and the .qtr file, close and restart Qtractor, the unwanted Pgm Change appears again and breaks my composition. A workaround to start with another Pgm Change at 1.1.000 and to change to the wanted at 2.1.000 won't do the trick, there simply should be no Pgm Change in the timeline, where I did not add one myself. Regards, Ralf |
From: Rui N. C. <rn...@rn...> - 2015-04-03 11:33:37
|
On 04/03/2015 10:50 AM, Ralf Mardorf wrote: > Hi, > > I'm the composer, I'm the one who knows in what way external gear is > connected and used, so for good reasons I decided to have a Pgm Change > at time 2.1.000 in a clip from 1.1.000 to 11.1.000. How can I get rid of > the Pgm Change that Qtractor automatically adds at time 1.1.000? > you don't. > If I delete the unwanted Pgm Change and/or select "Program: (None)", > then save the .mid file and the .qtr file, close and restart Qtractor, > the unwanted Pgm Change appears again and breaks my composition. > > A workaround to start with another Pgm Change at 1.1.000 and to change > to the wanted at 2.1.000 won't do the trick, there simply should be no > Pgm Change in the timeline, where I did not add one myself. > it's NOT a bug, never was. it's just the way it is, in qtractor MIDI design model for a little less than a decade already. take note: 1) one MIDI track conveys to one and only MIDI channel, although you can have several MIDI tracks addressing the same MIDI channel. 2) a MIDI instrument bank and program are properties of a MIDI track and thus also of the corresponding MIDI channel; this time, you can only have one instrument bank/program setting per MIDI channel; a MIDI bank_select/program_change message is always sent through the assigned MIDI track's output bus/port on startup or immediately after the MIDI port connection eventually changes. 3) all the above happens independently of any MIDI clip content on playback, which might have its own MIDI bank_select/program_change events interleaved on the same channel: that's pretty legal MIDI form and qtractor will play that exactly as originally intended, however: 4) when writing to any new MIDI file on its own, be that created on recording, exporting, merging and most importantly, editing over an existing one, the qtractor's MIDI track bank/program properties (2) will get always written at the beginning of the sequence no matter what. 5) when reading any MIDI file, the earliest bank_select/program_change message that are found on each MIDI track or channel in sequence will be assigned and honored as the new MIDI intrument setting (bank, program) as for the current MIDI track being loaded, if not already set before. so, pragmatically speaking, if you want different MIDI instrument voicings playing, then you'll have to make it on different MIDI channels. hth. cheers -- rncbc aka. Rui Nuno Capela |
From: Ralf M. <ral...@al...> - 2015-04-03 12:15:06
|
Hi Rui On Fri, 3 Apr 2015 12:33:15 +0100, Rui Nuno Capela wrote: >it's NOT a bug, never was. it's just the way it is, in qtractor MIDI >design model for a little less than a decade already. For a sequencer it anyway still is a bug. >so, pragmatically speaking, if you want different MIDI instrument >voicings playing, then you'll have to make it on different MIDI >channels. Fortunately this even isn't true for Qtractor. It's possible to change the program within one MIDI track. Some sounds need to be used this way, e.g. the European DX7 factory Cartridge sounds "ST.HELENS" and "EXPLOSION", since the sound "ST.HELENS" is needed to trigger the sound "EXPLOSION" by a program change. It's absolutely against MIDI standards and against human sense to enforce a program chance at the start position, when a program change is found at a later position. For example, you're using a sequencer for improvisation. By hand, not by a sequencer you are playing a synth, after a while you start the sequencer that in addition to you plays the same synth and after a while later, the sequencer should change the program number. It's common practise to do something like this, it's not freakish and the MIDI standard implies this option. No matter how you look at it, it's a bug. The sequencer should record and play what the musician plays. Regards, Ralf |
From: Ralf M. <ral...@al...> - 2015-04-03 12:37:29
|
PS: And what, if the MIDI interface at start position is on heavy traffic and data for some channels could be send at later positions to avoid unneeded traffic? Most of the times it's possible to add an empty bar at the beginning, but that can't be done always. If it can't be done, it's important to move program changes and similar stuff to later positions in the timeline when ever possible. |
From: Rui N. C. <rn...@rn...> - 2015-04-03 13:40:54
|
On 04/03/2015 01:37 PM, Ralf Mardorf wrote: > PS: > > And what, if the MIDI interface at start position is on heavy traffic > and data for some channels could be send at later positions to avoid > unneeded traffic? Most of the times it's possible to add an empty bar at > the beginning, but that can't be done always. If it can't be done, it's > important to move program changes and similar stuff to later positions > in the timeline when ever possible. > MIDI traffic is NOT the problem per se. whet you are probably thinking of is that (some old, the older the worse) MIDI instruments, as actual sound generators, synths, samplers, whatever, due to their sole electronic/mechanical/digital implementation, might react in a non negligible extent of time for such MIDI setup messages, like bank_select, program_change, (N)RPN, sysex, etc., and the effects of which might not be immediately available or evident--that's why all performance events are/were usually delayed a bar or so after the instrument setup data. of course this has nothing to do with the MIDI spec "tout couer" but it is/was a pragmatic convention, good practice and/or recommendations for GS/XG sequencing from which qtractor followed suit and enforced in its design model as a MIDI sequencer. again, as said earlier, you can have program_change events interleaved in the sequence whenever you like, provided the imported MIDI file was assembled elsewhere but on qtractor. the issue arises when qtractor deos re-create/re-write the MIDI file seguence, where it always inserts the MIDI track instrument parameters (bank_select, program_change) at the beginning (at BBT=1.1.0000) of the corresponding channel sequence. again, this is NOT a BUG. rather it's WAD, working as (long ago) designed. byee -- rncbc aka. Rui Nuno Capela |