Association of Track Name to Channels Incomplete #31
Comments
Yes, it is very common. For instance, a piano piece using only channel 1, and program 1, may very well have 2 tracks: one for the left hand and another for the right hand. It is equally common that this kind of files have a single track, but using two channels, one for each hand. But you may have observed that in the channels windows the channel names are editable. They may appear empty, but you can fill and edit the channel names yourself:
And if you activate in the Preferences dialog the option "Automatically Load and Save Song Settings", your edits become persistent, and will be shown the next time you open the song (even after restarting the application):
Note: the saved settings are not stored in the MIDI file, but on a config file located at the %USERPROFILE%\.dmidiplayer directory. |
|
I did notice i could edit the channel names, but I didn't pick up on the
fact that I could save that with the songs. That definitely helps. Thanks
Pedro.
…On Sun, Dec 8, 2024, 12:22 PM Pedro López-Cabanillas < ***@***.***> wrote:
Note: It is, of course, possible that a given channel could appear in two
different tracks. I am not experienced enough to know if such a situation
is common or not; or if there any conventions around this.
Yes, it is very common. For instance, a piano piece using only channel 1,
and program 1, may very well have 2 tracks: one for the left hand and
another for the right hand. It is equally common that this kind of files
have a single track, but using two channels, one for each hand.
But you may have observed that in the channels windows the channel names
are editable. They may appear empty, but you can fill and edit the channel
names yourself:
imagen.png (view on web)
<https://github.com/user-attachments/assets/0028954c-93d8-420f-abbe-cbc959c33842>
And if you activate in the Preferences dialog the option "Automatically
Load and Save Song Settings", your edits become persistent, and will be
shown the next time you open the song (even after restarting the
application):
imagen.png (view on web)
<https://github.com/user-attachments/assets/33a372c2-a5c5-4fca-8778-a46af7ea88e9>
Note: the saved settings are not stored in the MIDI file, but on a config
file located at the %USERPROFILE%\.dmidiplayer directory.
—
Reply to this email directly, view it on GitHub
<#31 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGKH7CCPSLH4CI6Q6XZ6NPL2ER55JAVCNFSM6AAAAABTHL5NX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRWGI3TCNZZG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I have an observation, which I am here submitting as an enhancement request; which you may, of course, elect to ignore.
Background: I am working on a Python script to take in a MIDI file, inspect it, accept some user input via a terminal, and then produce a new output MIDI file that has a Count-In sequence pre-pended onto the beginning of it. I am doing this to help me, and a few others, make use of MIDI files for learning and practising how to play songs. MIDI files are particularly useful for this due to the ability to control the played audio of each score's part independently. I.e., 'mute all parts except the one I am playing.' 'Mute my part so I can practice playing along with the group.' Etc.
Need: In the MIDI players used for this purpose it is important to be able to see the score's part name much more so than the channel number. In the software I am using to produce the original MIDI files this is done by using Tracks, and the 'Track-Name' meta message, to contain the score's part name - e.g., "Melody," "Harmony," etc.
Observation: For me, Drumstick MIDI File Player Multiplatform is actually pretty much OK about this. The "MIDI Channels" window lists all the in-use channels and shows both the Track Name and the General MIDI Patch name associated with each channel. Many MIDI players completely ignore the Track Name, so I'm happy with Drumstick MIDI File Player Multiplatform for this. However, Drumstick MIDI File Player Multiplatform only picks-up and displays the Track Name for the first channel it encounters in a given track. So, depending on how the MIDI file was created the "MIDI Channels" display may have several channel rows with blank Track Name attributes. See screenshot attached below.
Request: For every channel listed, display the Track Name that channel is associated to. Note: It is, of course, possible that a given channel could appear in two different tracks. I am not experienced enough to know if such a situation is common or not; or if there any conventions around this. For my part I'd say set a rule to just pickup the Track Name of the first Track any given channel appears in.
For my specific use case ideally there'd be a view that is Track oriented vs Channel oriented. That is, a view that lists all tracks, and then indented a bit under each track show the channels in use in that Track, along with the instrument patch for that channel.
More Notes: I am using the Musescore sheet music application to produce my source MIDI files. Musescore has an annoying feature of 'playing' the backing chords on the sheet music. It puts the backing chords into a separate channel, but in the same track as the score's part the chords are a part of. All that makes sense and, if they are going to do that I'd say this was a good way to structure the MIDI file for those. However, in all MIDI players this just adds complexity and confusion for most folks as it is hard to see what's going on. Unfortunately, even when I mute the backing chords within Musescore prior to MIDI export Musescore still puts the extra channel in, and all the notes - it just writes them all with velocity=0. So, I can't seem to get rid of them. Once I get this working for Musescore produced MIDI files I will be using it for MIDI files created from other sources as well - and no doubt I'll be in for further complications once I get to that point.
Example: Below is a list of docs that represents an example of this observation & request.
The text was updated successfully, but these errors were encountered: