> Splitting on silence isn't a real solution, and let's not bother with
> any of that.
OK.
> The real problem is the file obviously needs more than 16
> channels. (Don't know how I missed that. BLIND! The name is DuMass.)
> [...]
> The way we need to handle this kind of scenario is something like:
>
> 1. Determine that more than 16 channels are needed
> 2. Create a new device in the Studio for every multiple of 16 required
> 3. Leave user to make the devices point to something
> We could determine 1 by noting the number of program changes at the
> start of the file on a given channel. Three program changes on channel
> 1, three banks of 16, make three devices, allocate the events to #1 on
> each device in series. (I know your channel allocator might obviate the
> need to create all three devices, but it's simpler to go with a
> structure that could contain everything if all three banks of 16
> channels were full.)
It may be more complicated. I just looked at a trace of loading MidiFile,
and every track starts with a program change. Some are obviously intended
to share a channel (eg piano right hand, piano left hand). Some obviously
aren't (eg piccolo & harp).
We could detect whether the programs are the same (including bank etc).
But right now MidiFile only tries to understand program after it has
assigned channels to all tracks. So there's real rewriting of MidiFile
involved.
Alternatively we could never merge, and every track gets its own channel
even if that pushes us onto second, third, etc devices. But this seems
like it would cause needless problems.
So what's a reasonable way for MidiFile::convertToRosegarden to proceed?
ISTM we should keep track of the InstrumentIds each original-channel has
used, and use that to check whether a track can re-use an InstrumentId or
must make a new one.
> What to do for these extra devices we'd have to create is a really ugly
> problem though. Saving a lot of discussion, the gist of it is that it
> has the potential to clobber all the program and controller information.
>
> I guess the only practical thing to do is:
>
> 1. Map the first 16 channels to device 0
> 2. If device n exists (starting with 1), map the next 16 to device n
> 3. If no device n, clone device 0 as n, map to n
> 4. GOTO 2 until everything is mapped to a device and all parts imported
This part may actually be easier. Since posting, I've looked at how
MidiFile does it and traced execution. We actually hit the problem
earlier than I thought. Studio is already somewhat doing the right thing,
but it is fed wrong InstrumentIds (always MidiInstrumentBase + original
channel)
ISTM it just needs a way for getInstrumentById to be forced to provide a
real instrument, making one if needed (within reason, up to
AudioInstrumentBase or whatever fixed number is next)
> I spent way more time than I had to allocate on this, so I have to leave
> it here and go. If this whole idea isn't clear, please, let's discuss
> more before doing anything.
Yes, definitely. I value the discussion, especially when you and others
point out when my ideas are off in the wrong direction.
Tom Breton (Tehom)
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
