Robert Hänggi
2017-07-03 06:18:36 UTC
Hi Pokechu22
Thanks for your work on MIDI.
I'm less interested in scrubbing than in having fundamental features
ready for 2.2.0.
For a multi-track project, it is essential to be able to make
gain-staging (and pan-staging as a second option).
Hence my questions:
- How do keyboard users change Gain/Volume/Velocity?
- How do I interpret the velocity values in the *.aup files?
Neither do They seem related to the normal data range 0-127 nor to dB
values (-60.0 gives a reduction of 12 dB after recording/rendering).
Roger has some knowledge in the field of Velocity to dB
interpretation. See e.g. his paper
http://quod.lib.umich.edu/i/icmc/bbp2372.2006.042?rgn=main;view=fulltext
So I wonder if we should show
- the normal gain dialog for MIDI on the focused track
- a Velocity dialog (with range 0 - 127) instead.
- both at the same time but dB as informal interpretation.
- an additional control for the mapping velocity-dB (logarithmic or
square root with an optional dynamic range)
- and/or include the latter in the MIDI preferences
Note that we have also two shortcuts for adjusting the gain on the
focused track in 1 dB steps.
I think they should also move the velocity slider.
I assume that the velocity is automatically set to either maximum or mean.
Which one?
BTW, the velocity slider should actually be a volume control--they are
not the same.
Regards
Robert
Thanks for your work on MIDI.
I'm less interested in scrubbing than in having fundamental features
ready for 2.2.0.
For a multi-track project, it is essential to be able to make
gain-staging (and pan-staging as a second option).
Hence my questions:
- How do keyboard users change Gain/Volume/Velocity?
- How do I interpret the velocity values in the *.aup files?
Neither do They seem related to the normal data range 0-127 nor to dB
values (-60.0 gives a reduction of 12 dB after recording/rendering).
Roger has some knowledge in the field of Velocity to dB
interpretation. See e.g. his paper
http://quod.lib.umich.edu/i/icmc/bbp2372.2006.042?rgn=main;view=fulltext
So I wonder if we should show
- the normal gain dialog for MIDI on the focused track
- a Velocity dialog (with range 0 - 127) instead.
- both at the same time but dB as informal interpretation.
- an additional control for the mapping velocity-dB (logarithmic or
square root with an optional dynamic range)
- and/or include the latter in the MIDI preferences
Note that we have also two shortcuts for adjusting the gain on the
focused track in 1 dB steps.
I think they should also move the velocity slider.
I assume that the velocity is automatically set to either maximum or mean.
Which one?
BTW, the velocity slider should actually be a volume control--they are
not the same.
Regards
Robert
I've finished up my second round of EXPERIMENTAL_MIDI_OUT changes.
- 5e2e2d4cdb "Add more method and field documentation": General
documentation improvements, which I used to first get an understanding
of
the code. No actual logic changes.
Removes unused methods (some of which were already commented out)
- f5645b5689 "Fix drawing MIDI channels with IDs greater than 16": A bug
fix for MIDI files that have more than 16 channels (which can happen via
allegro and certain other MIDI files).
- d313ef7ef5 "Re-add automake files for portmidi", 8a587e7a5e "Attempt
to add the rest of the makefile for portmidi", 9a87587028 "Regenerate
configure scripts and Makefile.in's": An attempt at fixing building for
portmidi. I can't say whether this actually works (I think it doesn't),
but it is at least a starting point that someone who actually
understands
automake (or has a computer fast enough to mess with this without
waiting
an hour to see what was wrong; my pi is definitely suboptimal for
testing).
- 45ddc27589 "Add MIDI device diagnostics": Adds an option under Help ->
Diagnostics to view MIDI device info, similar to the existing option for
audio devices.
- 1308a0486e "Fix velocity offset edge case": Bug fix for a potential
edge case with the velocity slider.
- 0ffd7a88b5 "Fix cut preview with note tracks": Fixes and enables cut
preview for note tracks.
Makes use of the mouse wheel with the vertical ruler for note tracks
(the
piano). Behavior's the same as with normal wave tracks: control zooms
in
and out, and shift scrolls up and down.
- 2113b798e7 "Implement Shift+Right-click for full extent on the note
holding shift to show the full extent.
- 8d470e0821 "Fix note track status message": corrects a typo in the
status message for the note track VRuler (and just makes the message the
same as the one for wave tracks).
- 0251bc0277 "Use mTimeTrack timing rather than mMidiPlaySpeed": Time
track implementation, same as the one that was previously used, except
now
it's stable and behaves correctly
what it says on the tin. This commit is separate since it may be
beneficial to skip or revert it (more on this later).
- d8ef0bcce3 "Get scrubbing to work with MIDI playback": This actually
fixes scrubbing with MIDI. See the commit for details on the change and
potential caveats.
- d144edcef2 "Update documentation for MIDI with time tracks and
scrubbing": A documentation update for some of the previous changes
- 6abac91a11 "Remove MIDI-only playback (without portaudio) logic": This
is probably the most important commit. It drops out the code for
playing
note tracks without using portaudio timing; instead, a portaudio stream
is
always started. This greatly helps with synchronization; for instance,
it
ensures that recording syncs up with MIDI (tested via playing a ~6
minute
long file via a loopback cable; without this commit, it desyncs by the
end,
but with it, it remains in sync the entire way). It also just reduces
duplicate code, meaning that e.g. scrubbing logic only happens in one
place. The actual change here is just one line: changing 'if(
playbackTracks.size() > 0 )' to 'if (playbackTracks.size() > 0 ||
midiPlaybackTracks.size() > 0)' in AudioIO::StartStream (the rest of the
changes are documentation and removing the previous special-case code).
There are still a few bugs that need to be fixed, but I feel like these
changes are all ready to go and everything else should be fairly simple bug
- Scrubbing doesn't work with only a note track; time just doesn't
advance. (This is somewhat better than when scrubbing was completely
ignored; my guess as to why this is happening is that some assumption
about
wave tracks is being violated, for instance maxLen is always 0 in
audacityAudioCallback).
- The play button doesn't become unpressed when the end of the file is
reached when there's only a note track; stop must manually be clicked.
Both of these are in parts of the code which I'm not fully familiar with,
so if someone else has an idea of how to handle it, that'd be helpful (I'll
take a look later today too though).
- Scrubbing with MIDI does not work in reverse. Notes simply are not
played again if they've already been played; this was too complicated
for
me to implement at the time.
I do not attempt to make this clearer within the UI; playback can be
attempted backwards and the notes just won't occur. What to do with
this
will vary; perhaps we could simply block scrubbing backwards with MIDI
for
now?
All of this code is on my midi-out-2
<https://github.com/pokechu22/audacity/tree/midi-out-2> branch.
--Poke
- 5e2e2d4cdb "Add more method and field documentation": General
documentation improvements, which I used to first get an understanding
of
the code. No actual logic changes.
Removes unused methods (some of which were already commented out)
- f5645b5689 "Fix drawing MIDI channels with IDs greater than 16": A bug
fix for MIDI files that have more than 16 channels (which can happen via
allegro and certain other MIDI files).
- d313ef7ef5 "Re-add automake files for portmidi", 8a587e7a5e "Attempt
to add the rest of the makefile for portmidi", 9a87587028 "Regenerate
configure scripts and Makefile.in's": An attempt at fixing building for
portmidi. I can't say whether this actually works (I think it doesn't),
but it is at least a starting point that someone who actually
understands
automake (or has a computer fast enough to mess with this without
waiting
an hour to see what was wrong; my pi is definitely suboptimal for
testing).
- 45ddc27589 "Add MIDI device diagnostics": Adds an option under Help ->
Diagnostics to view MIDI device info, similar to the existing option for
audio devices.
- 1308a0486e "Fix velocity offset edge case": Bug fix for a potential
edge case with the velocity slider.
- 0ffd7a88b5 "Fix cut preview with note tracks": Fixes and enables cut
preview for note tracks.
Makes use of the mouse wheel with the vertical ruler for note tracks
(the
piano). Behavior's the same as with normal wave tracks: control zooms
in
and out, and shift scrolls up and down.
- 2113b798e7 "Implement Shift+Right-click for full extent on the note
holding shift to show the full extent.
- 8d470e0821 "Fix note track status message": corrects a typo in the
status message for the note track VRuler (and just makes the message the
same as the one for wave tracks).
- 0251bc0277 "Use mTimeTrack timing rather than mMidiPlaySpeed": Time
track implementation, same as the one that was previously used, except
now
it's stable and behaves correctly
what it says on the tin. This commit is separate since it may be
beneficial to skip or revert it (more on this later).
- d8ef0bcce3 "Get scrubbing to work with MIDI playback": This actually
fixes scrubbing with MIDI. See the commit for details on the change and
potential caveats.
- d144edcef2 "Update documentation for MIDI with time tracks and
scrubbing": A documentation update for some of the previous changes
- 6abac91a11 "Remove MIDI-only playback (without portaudio) logic": This
is probably the most important commit. It drops out the code for
playing
note tracks without using portaudio timing; instead, a portaudio stream
is
always started. This greatly helps with synchronization; for instance,
it
ensures that recording syncs up with MIDI (tested via playing a ~6
minute
long file via a loopback cable; without this commit, it desyncs by the
end,
but with it, it remains in sync the entire way). It also just reduces
duplicate code, meaning that e.g. scrubbing logic only happens in one
place. The actual change here is just one line: changing 'if(
playbackTracks.size() > 0 )' to 'if (playbackTracks.size() > 0 ||
midiPlaybackTracks.size() > 0)' in AudioIO::StartStream (the rest of the
changes are documentation and removing the previous special-case code).
There are still a few bugs that need to be fixed, but I feel like these
changes are all ready to go and everything else should be fairly simple bug
- Scrubbing doesn't work with only a note track; time just doesn't
advance. (This is somewhat better than when scrubbing was completely
ignored; my guess as to why this is happening is that some assumption
about
wave tracks is being violated, for instance maxLen is always 0 in
audacityAudioCallback).
- The play button doesn't become unpressed when the end of the file is
reached when there's only a note track; stop must manually be clicked.
Both of these are in parts of the code which I'm not fully familiar with,
so if someone else has an idea of how to handle it, that'd be helpful (I'll
take a look later today too though).
- Scrubbing with MIDI does not work in reverse. Notes simply are not
played again if they've already been played; this was too complicated
for
me to implement at the time.
I do not attempt to make this clearer within the UI; playback can be
attempted backwards and the notes just won't occur. What to do with
this
will vary; perhaps we could simply block scrubbing backwards with MIDI
for
now?
All of this code is on my midi-out-2
<https://github.com/pokechu22/audacity/tree/midi-out-2> branch.
--Poke