|
|
|
dev:instruments_and_devices [2018/02/07 16:07]
|
dev:instruments_and_devices [2022/05/06 16:07] (current)
|
| | ====Problem description==== |
| | |
| | |
| | We would like a way to insert MIDI program changes in the middle of tracks. |
| | |
| | This is a common feature in many sequencer programs, but it is not currently |
| | supported by RG. Also, the "import MIDI files" function can't be properly |
| | fixed now to process MIDI files having PC events in the middle of the tracks. |
| | |
| | ====Proposal summary==== |
| | |
| | Put program changes at the beginning of the segments. Implement this in |
| | Rosegarden associating the Instrument (which holds the bank/program numbers) |
| | to the Segment class instead of the Track. Change the MIDI file import |
| | function to create a new segment whenever it finds a bank/program change |
| | events in the middle of a track. |
| | |
| | ====Discussion==== |
| | |
| | <code> |
| | On Tuesday 20 Jun 2006 21:04, Pedro Lopez-Cabanillas wrote: |
| | > On Monday, 19 June 2006 18:32, Chris Cannam wrote: |
| | > > Note that none of this is an issue when importing MIDI files, because |
| | > > each distinct program gets separated out to a distinct track |
| | > |
| | > This isn't the current behavior of the MIDI import function, and I don't |
| | > remember it was as you say in the past. |
| | |
| | No, you're right. I was thinking of tracks that have channel events sent to |
| | more than one channel, which we split out into more than one track in order |
| | to assign each to a different instrument. |
| | |
| | > On the other hand, I find some features related to Instruments very poor or |
| | > even wrong. For instance: why the MIDI channel is an attribute of the |
| | > Instrument? why the Instruments are attributes of the tracks instead of the |
| | > segments? And as a consequence: there shouldn't be a limitation of 16 |
| | > instruments per device. |
| | |
| | 16 instruments per device is an arbitrary number that just coincidentally |
| | happens to be the same as the number of MIDI channels. If you change the 16 |
| | at AlsaDriver.cpp line 1005 to something else, you'll get a different number. |
| | It works just as well with 24 or 32, or 200 -- try it! |
| | |
| | But I fear and mistrust the instrument/device handling code, and particularly |
| | the logic that creates the instruments in the first place and tries to keep |
| | them in sync between GUI and sequencer. |
| | |
| | For example, look at what the .rg file loader (rosexmlhandler.cpp:1868 and |
| | thereabouts) does when reading the instrument elements within each device |
| | element. It looks up the instrument according to its ID, which is a global |
| | numbering from 2000 upwards for MIDI instruments, and applies the given bank |
| | and program to that instrument if it exists, dropping them entirely if it |
| | doesn't. |
| | |
| | The significant points are (a) this code never actually creates instruments or |
| | assigns instrument IDs to devices -- that's done when the devices are |
| | created, which is originated by the sequencer if the devices are created to |
| | match existing available MIDI connections -- and (b) the instrument ID is not |
| | local to the device, but global. Put together, this means this code has no |
| | way of dealing with (or really knowing about) the situation where an |
| | instrument ID is found on the wrong device. For example, if you save a file |
| | with 16 instruments per device (so that instrument IDs 2000-2015 are on |
| | device 0, 2016-2031 on device 1 etc), then increase the number of |
| | auto-generated instruments per device to 24 and reload the file, the |
| | instruments 2016-2023 will have moved from device 1 to device 0 and tracks |
| | set to those instruments will suddenly play through a different MIDI port. |
| | |
| | The root cause of this is that instruments are being created in the wrong |
| | place -- they're created on the whim of the sequencer, and then propagated |
| | back to the GUI. This happens because we want to make sure there are |
| | candidate instruments with likely connections available for the MIDI ports |
| | that the sequencer finds on startup. As a result the code that really should |
| | have the ultimate control over the device and instrument setup (the code that |
| | reads in the saved devices and instruments from the .rg file) doesn't have |
| | any real control at all, because the instruments are already there. It can |
| | ask for the sequencer to create a new device, but it's still at the mercy of |
| | the sequencer's built-in count of instruments for that device. In fact, all |
| | the instruments and devices should be created at the GUI, or at least the GUI |
| | should have control over when and what is created -- only the available |
| | connections should be managed on the sequencer side. |
| | |
| | > My proposal is to associate Instruments to segments instead of tracks, and |
| | > dissociate the MIDI channels from instruments moving them to the track |
| | > level. |
| | |
| | I'm not sure that this latter bit is necessary, if there can in fact be more |
| | or less than 16 instruments per device -- is it? Would it make much |
| | difference either way? |
| | |
| | Associating instruments with segments seems at first glance like an excellent |
| | idea. I wonder if there are any big disadvantages? It sounds equally useful |
| | for audio instruments, to allow you to apply different effects plugins to |
| | different segments on the same track. |
| | |
| | |
| | [ later ] |
| | |
| | |
| | > Yes, but the extra instruments don't bring any extra advantage. |
| | |
| | Not in terms of the overall capability, but that's a limitation of MIDI (as |
| | there only are 16 channels and you can't have two different programs on the |
| | same one at the same time). I was just making the aside that the number of |
| | instruments is not technically fixed to the number of MIDI channels. (It |
| | could be an advantage to have more, simply from a management point of view -- |
| | assign separate instruments to all of your tracks and then worry about which |
| | channels to play them through afterwards. That's not very relevant though.) |
| | |
| | But you're right, if you make the instruments per-segment and channels |
| | per-track, the problem goes away. Nice. |
| | |
| | > I don't understand why the methods generateInstruments() and |
| | > addInstrumentsForDevice() are members of the class AlsaDriver. |
| | |
| | I sort-of answered this in the previous email -- the AlsaDriver creates a |
| | default set of instruments to match up with the available output ports it |
| | finds on startup. That's really the only reason this logic is there. The |
| | original idea was probably to have the set of instruments completely fixed by |
| | the sequencer -- you'd have to look at the aRts driver to see what the |
| | initial design was, it's probably quite different (and simpler). |
| | |
| | > The sequencer doesn't need to care about the Instruments at all. |
| | |
| | Not true -- it needs to know about instruments because it also sequences to |
| | things other than MIDI devices (e.g. synth plugins -- and note that DSSI |
| | plugins don't have channels). Receiving events associated with particular |
| | instruments, and then doing the mapping from instrument to output type based |
| | on a separate relationship between the two, is probably the right thing. |
| | It's just a question of who creates and manages that relationship. |
| | |
| | > It is not strictly necessary, but may be a nightmare otherwise. Imagine |
| | > this scenario: track one has two segments, both assigned to channel#1. |
| | > Second track has an instrument assigned to channel#2. If you change the |
| | > instrument for the second segment on the first track, and assign an |
| | > instrument having channel #2, you are changing in fact the program for the |
| | > second track. |
| | |
| | Yes, with this and the earlier example I'm convinced. |
| | |
| | > Can it be useful for DSSI instruments too? I think so, but I don't know too |
| | > much the internals. |
| | |
| | I would expect so. |
| | |
| | Quite a bit of work though, all in all. |
| | |
| | </code> |
| |
