Fixing EXPERIMENTAL_MIDI_OUT

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fixing EXPERIMENTAL_MIDI_OUT

Pokechu22
Hey everyone.

I've recently been working on fixing EXPERIMENTAL_MIDI_OUT.  Initially
I just started because I wanted to clean up the UX for toggling midi
channels (which could be done even when the buttons weren't rendered
since EXPERIMENTAL_MIDI_OUT wasn't enabled), but when I found out how
close this feature was to functional, I decided I want to get it fully
up to date.

You can see my first attempt on PR #177
(https://github.com/audacity/audacity/pull/177); I've closed that
though because it's not very good and doesn't cover all cases (plus it
still has a lot of the code hackilly written).  I'm currently trying
again with a more general rework (with the same general ideas as that
PR, but done somewhat better).

If there's anything that I should know regarding EXPERIMENTAL_MIDI_OUT
(or comments regarding that PR), I'd very much appreciate hearing
them, thanks!

--Poke

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

James Crook
Hi Poke,

This is great to hear.

Changes that make EXPERIMENTAL_MIDI_OUT work well, and that don't affect
Audacity when it is not defined are very welcome.

Moving to defining EXPERIMENTAL_MIDI_OUT by default in Audacity is
likely to take a lot more work than that.  I'm seeing code for example
that uses mLeftTrack in standard Audacity and mTrack with
EXPERIMENTAL_MIDI_OUT.  That suggests to me that there will be issues
with stereo mixing with EXPERIMENTAL_MIDI_OUT....

If EXPERIMENTAL_MIDI_OUT is to become mainstream we need to be confident
in its stability.  Probably it won't go live until we have moved a lot
of it into its own files - refactoring it out of TrackPanel, AudioIO and
MixerBoard, so we can see it more independently of the other code.  
Exactly how needs discussion, so I am glad you came here and asked
rather than just sending pull requests.

One possibility when EXPERIMENTAL_MIDI_OUT is further along is that we
could distribute experimental builds with it enabled. This would give us
user feedback on stability and issues.

Thanks for getting in contact.

--James.




On 2/11/2017 3:10 AM, Pokechu22 wrote:

> Hey everyone.
>
> I've recently been working on fixing EXPERIMENTAL_MIDI_OUT.  Initially
> I just started because I wanted to clean up the UX for toggling midi
> channels (which could be done even when the buttons weren't rendered
> since EXPERIMENTAL_MIDI_OUT wasn't enabled), but when I found out how
> close this feature was to functional, I decided I want to get it fully
> up to date.
>
> You can see my first attempt on PR #177
> (https://github.com/audacity/audacity/pull/177); I've closed that
> though because it's not very good and doesn't cover all cases (plus it
> still has a lot of the code hackilly written).  I'm currently trying
> again with a more general rework (with the same general ideas as that
> PR, but done somewhat better).
>
> If there's anything that I should know regarding EXPERIMENTAL_MIDI_OUT
> (or comments regarding that PR), I'd very much appreciate hearing
> them, thanks!
>
> --Poke
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Stevethefiddle
Great to see some work on MIDI.

Steve

On 11 February 2017 at 10:27, James Crook <[hidden email]> wrote:

> Hi Poke,
>
> This is great to hear.
>
> Changes that make EXPERIMENTAL_MIDI_OUT work well, and that don't affect
> Audacity when it is not defined are very welcome.
>
> Moving to defining EXPERIMENTAL_MIDI_OUT by default in Audacity is
> likely to take a lot more work than that.  I'm seeing code for example
> that uses mLeftTrack in standard Audacity and mTrack with
> EXPERIMENTAL_MIDI_OUT.  That suggests to me that there will be issues
> with stereo mixing with EXPERIMENTAL_MIDI_OUT....
>
> If EXPERIMENTAL_MIDI_OUT is to become mainstream we need to be confident
> in its stability.  Probably it won't go live until we have moved a lot
> of it into its own files - refactoring it out of TrackPanel, AudioIO and
> MixerBoard, so we can see it more independently of the other code.
> Exactly how needs discussion, so I am glad you came here and asked
> rather than just sending pull requests.
>
> One possibility when EXPERIMENTAL_MIDI_OUT is further along is that we
> could distribute experimental builds with it enabled. This would give us
> user feedback on stability and issues.
>
> Thanks for getting in contact.
>
> --James.
>
>
>
>
> On 2/11/2017 3:10 AM, Pokechu22 wrote:
>> Hey everyone.
>>
>> I've recently been working on fixing EXPERIMENTAL_MIDI_OUT.  Initially
>> I just started because I wanted to clean up the UX for toggling midi
>> channels (which could be done even when the buttons weren't rendered
>> since EXPERIMENTAL_MIDI_OUT wasn't enabled), but when I found out how
>> close this feature was to functional, I decided I want to get it fully
>> up to date.
>>
>> You can see my first attempt on PR #177
>> (https://github.com/audacity/audacity/pull/177); I've closed that
>> though because it's not very good and doesn't cover all cases (plus it
>> still has a lot of the code hackilly written).  I'm currently trying
>> again with a more general rework (with the same general ideas as that
>> PR, but done somewhat better).
>>
>> If there's anything that I should know regarding EXPERIMENTAL_MIDI_OUT
>> (or comments regarding that PR), I'd very much appreciate hearing
>> them, thanks!
>>
>> --Poke
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
rbd
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

rbd
In reply to this post by Pokechu22

That's great to hear. Only a couple of things come to mind about EXPERIMENTAL_MIDI_OUT:

  • Note Tracks were originally created using the allegro library. Allegro is both an in-memory representation and an external text-based file format. Allegro is much more general than MIDI, supporting "notes" with lists of attribute/value properties, and "updates" which are time-stamped attribute/value pairs associated with "notes". Because "values" can be strings, floats, ints, etc., values are tagged with type codes and there's a lot of dynamic allocation. C++ is not ideal for this because in the library there are lots of cases where an event ("note" or "update") is referenced from multiple places. If you delete a track and all it's events, you might create dangling pointers elsewhere, but if you don't delete the events, you might leak memory. This *could* be solved with smart pointers, explicit ref. counting, or even garbage collection, but at least at the time this was all designed, we thought managing "by hand" would save a lot of memory and not be that difficult -- still, if you go in with the wrong expectations or simply ignore memory allocation/deallocation, you won't get very far. On the other hand, Allegro has some *very* powerful and high-level operations to support cut, copy, paste, stretch, mapping from time to beats ("time maps" or "tempo maps"), etc., plus midi file and allegro format import/export. That was a *lot* of work, much of it pretty tricky with lots of edge cases.
  • There is a lot of code for synchronizing audio to MIDI. PortMidi includes the ability to provide an external clock for synchronization. Since audio clocks and system clocks are not synchronized (your audio sample clock runs off a hardware crystal oscillator that's separate from whatever the OS uses for time), I use PortAudio's sample count as a time reference for MIDI. This is somewhat tricky because audio might not be running, audio starts and stops, and the OS may not give PortAudio all the info it needs to compute the current sample position accurately. Nevertheless, I think the implementation is pretty good. What happens between Audacity and PortMidi is Audacity generates timestamped MIDI messages and delivers them to PortMidi more-or-less at the same time any corresponding audio samples are delivered to PortAudio. PortMidi then (1) translates the timestamp to system time (which is just adding an offset), (2) adds a "latency" offset -- where latency is set to match the audio latency of the system, (3) PortMidi then uses the MIDI device driver to get the best timing accuracy possible. The goal is for MIDI messages to be finally delivered just as corresponding audio samples are hitting the DAC.

Let me know if you have questions - this has been "swapped out" quite awhile, but it would be cool to get it in production.

-Roger


On 2/10/17 10:10 PM, Pokechu22 wrote:
Hey everyone.

I've recently been working on fixing EXPERIMENTAL_MIDI_OUT.  Initially
I just started because I wanted to clean up the UX for toggling midi
channels (which could be done even when the buttons weren't rendered
since EXPERIMENTAL_MIDI_OUT wasn't enabled), but when I found out how
close this feature was to functional, I decided I want to get it fully
up to date.

You can see my first attempt on PR #177
(https://github.com/audacity/audacity/pull/177); I've closed that
though because it's not very good and doesn't cover all cases (plus it
still has a lot of the code hackilly written).  I'm currently trying
again with a more general rework (with the same general ideas as that
PR, but done somewhat better).

If there's anything that I should know regarding EXPERIMENTAL_MIDI_OUT
(or comments regarding that PR), I'd very much appreciate hearing
them, thanks!

--Poke

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Pokechu22-2
On Sat, Feb 11, 2017 at 2:27 AM, James Crook <[hidden email]> wrote:
Moving to defining EXPERIMENTAL_MIDI_OUT by default in Audacity is
likely to take a lot more work than that.  I'm seeing code for example
that uses mLeftTrack in standard Audacity and mTrack with
EXPERIMENTAL_MIDI_OUT.  That suggests to me that there will be issues
with stereo mixing with EXPERIMENTAL_MIDI_OUT....
 
If EXPERIMENTAL_MIDI_OUT is to become mainstream we need to be confident
in its stability.  Probably it won't go live until we have moved a lot
of it into its own files - refactoring it out of TrackPanel, AudioIO and
MixerBoard, so we can see it more independently of the other code.
Exactly how needs discussion, so I am glad you came here and asked
rather than just sending pull requests.
 
There's a comment (from 0870fdec) which relates to that:
 
//vvv Vaughan, 2010-11-05:
//    I suggest that when this is no longer experimental, rather than all these #ifdef's,
//    this be done by factoring, i.e., add two subclasses to MixerTrackCluster,
//    MixerNoteTrackCluster and MixerWaveTrackCluster, such that all the common
//    code is in the parent, and these #ifdef's are only around
//    MixerNoteTrackCluster rather than sprinkled throughout MixerTrackCluster.
 
I'm guessing that that would be a reasonable implementation.  The mixer code as-is seems to be fairly broken, such as casting all tracks to WaveTrack* (and then back to NoteTrack*) which seems to cause things to not work at all (the cast back seems to not occur).  I don't think left/right is an issue in the current implementation, but it's still ugly and should be removed if possible.

Also regarding the mixer, what's the point of the MusicalInstrument type (and related code)?  I can't see where that shows up on the actual program, but it sounds vaguely midi-related (yet, it isn't part of the midi code).

On Sat, Feb 11, 2017 at 6:52 AM, Roger Dannenberg <[hidden email]> wrote:

That's great to hear. Only a couple of things come to mind about EXPERIMENTAL_MIDI_OUT:

  • Note Tracks were originally created using the allegro library. Allegro is both an in-memory representation and an external text-based file format. Allegro is much more general than MIDI, supporting "notes" with lists of attribute/value properties, and "updates" which are time-stamped attribute/value pairs associated with "notes". Because "values" can be strings, floats, ints, etc., values are tagged with type codes and there's a lot of dynamic allocation. C++ is not ideal for this because in the library there are lots of cases where an event ("note" or "update") is referenced from multiple places. If you delete a track and all it's events, you might create dangling pointers elsewhere, but if you don't delete the events, you might leak memory. This *could* be solved with smart pointers, explicit ref. counting, or even garbage collection, but at least at the time this was all designed, we thought managing "by hand" would save a lot of memory and not be that difficult -- still, if you go in with the wrong expectations or simply ignore memory allocation/deallocation, you won't get very far. On the other hand, Allegro has some *very* powerful and high-level operations to support cut, copy, paste, stretch, mapping from time to beats ("time maps" or "tempo maps"), etc., plus midi file and allegro format import/export. That was a *lot* of work, much of it pretty tricky with lots of edge cases.
  • There is a lot of code for synchronizing audio to MIDI. PortMidi includes the ability to provide an external clock for synchronization. Since audio clocks and system clocks are not synchronized (your audio sample clock runs off a hardware crystal oscillator that's separate from whatever the OS uses for time), I use PortAudio's sample count as a time reference for MIDI. This is somewhat tricky because audio might not be running, audio starts and stops, and the OS may not give PortAudio all the info it needs to compute the current sample position accurately. Nevertheless, I think the implementation is pretty good. What happens between Audacity and PortMidi is Audacity generates timestamped MIDI messages and delivers them to PortMidi more-or-less at the same time any corresponding audio samples are delivered to PortAudio. PortMidi then (1) translates the timestamp to system time (which is just adding an offset), (2) adds a "latency" offset -- where latency is set to match the audio latency of the system, (3) PortMidi then uses the MIDI device driver to get the best timing accuracy possible. The goal is for MIDI messages to be finally delivered just as corresponding audio samples are hitting the DAC.

Let me know if you have questions - this has been "swapped out" quite awhile, but it would be cool to get it in production.

-Roger

Fortunately, the actual audio portion seems to mostly work (although it's not completely stable and hangs sometimes) without changes; it's mainly the UI that is broken currently.  However, this information's certainly useful, and should help with fixing the hanging (hopefully).  Regarding synchronization: one thing that doesn't seem to work is time tracks; note tracks just don't seem to use them.  But it seems to mostly stay in sync otherwise (I haven't tested it too extensively, though).

--Poke

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

James Crook
On 2/12/2017 5:02 AM, Pokechu22 wrote:
> Also regarding the mixer, what's the point of the MusicalInstrument type
> (and related code)?  I can't see where that shows up on the actual program,
> but it sounds vaguely midi-related (yet, it isn't part of the midi code).
That's entirely about bitmaps that show on the Mixerboard.
http://manual.audacityteam.org/man/view_menu.html#Mixer_Board...

the bitmaps of the guitars, trumpet, keyboard, percussion

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Pokechu22-2
Hey everyone,

I've gotten it mostly written at this point.  The code is on the
fix-midi-output branch on my fork
(https://github.com/Pokechu22/audacity/tree/fix-midi-output) and you
can get a compare view at
https://github.com/audacity/audacity/compare/master...Pokechu22:fix-midi-output?expand=1.
(I haven't submitted a pull request yet).

These changes cover more or less only the UI related to midi playback;
they make no changes to the actual playback code other than fixing a
few compile warnings and errors.  However, I think the UI changes are
fairly elegant and are beneficial even when EXPERIMENTAL_MIDI_OUT is
not enabled.

The mixer also supports note tracks, allowing changing the velocity
(instead of the gain as normally would be done).  Most of the
left/right issues you previously mentioned were not applicable; they
were only due to weird naming due to the way EXPERIMENTAL_MIDI_OUT was
previously done with the mixer.  I split it into 2 separate
MixerTrackCluster implementations, so while there still is both a
mTrack and an mLeftTrack/mRightTrack, mLeftTrack/mRightTrack are only
applicable to wave tracks.

I've also split the code for the midi channel toggle (the one seen on
http://manual.audacityteam.org/man/note_tracks.html) into its own
define (EXPERIMENTAL_MIDI_CONTROLS) so that it can be enabled without
midi output being enabled.  It's fairly stable (and in fact has been
clickable in current releases even though it doesn't render) and
probably should be enabled in all builds, even ones without
EXPERIMENTAL_MIDI_OUT.

There's still a few things that I know are broken, primarily time
tracks.  The actual midi output code in AudioIO is fairly complicated,
so I'm not completely sure whether I'd be able to handle that
immediately (I'm not completely comfortable with C++).  Should this
first part be sent as a PR for testing so that other similar bugs can
be found?

--Poke

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

James Crook
This sounds good.

I haven't had time to try it out yet.
I think we should at the very least, during 2.2.0 development, have an
experimental build with your changes in, encourage users to try it, and
get feedback.

We've been talking on wiki about using experimental builds that are
believed to be suitable for production work to grow our team of engaged
users who give feedback on work in progress.
http://wiki.audacityteam.org/wiki/New_Builds_Team

--James.

On 2/22/2017 2:29 AM, Pokechu22 wrote:

> Hey everyone,
>
> I've gotten it mostly written at this point.  The code is on the
> fix-midi-output branch on my fork
> (https://github.com/Pokechu22/audacity/tree/fix-midi-output) and you
> can get a compare view at
> https://github.com/audacity/audacity/compare/master...Pokechu22:fix-midi-output?expand=1.
> (I haven't submitted a pull request yet).
>
> These changes cover more or less only the UI related to midi playback;
> they make no changes to the actual playback code other than fixing a
> few compile warnings and errors.  However, I think the UI changes are
> fairly elegant and are beneficial even when EXPERIMENTAL_MIDI_OUT is
> not enabled.
>
> The mixer also supports note tracks, allowing changing the velocity
> (instead of the gain as normally would be done).  Most of the
> left/right issues you previously mentioned were not applicable; they
> were only due to weird naming due to the way EXPERIMENTAL_MIDI_OUT was
> previously done with the mixer.  I split it into 2 separate
> MixerTrackCluster implementations, so while there still is both a
> mTrack and an mLeftTrack/mRightTrack, mLeftTrack/mRightTrack are only
> applicable to wave tracks.
>
> I've also split the code for the midi channel toggle (the one seen on
> http://manual.audacityteam.org/man/note_tracks.html) into its own
> define (EXPERIMENTAL_MIDI_CONTROLS) so that it can be enabled without
> midi output being enabled.  It's fairly stable (and in fact has been
> clickable in current releases even though it doesn't render) and
> probably should be enabled in all builds, even ones without
> EXPERIMENTAL_MIDI_OUT.
>
> There's still a few things that I know are broken, primarily time
> tracks.  The actual midi output code in AudioIO is fairly complicated,
> so I'm not completely sure whether I'd be able to handle that
> immediately (I'm not completely comfortable with C++).  Should this
> first part be sent as a PR for testing so that other similar bugs can
> be found?
>
> --Poke
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Pokechu22-2
I've rebased my branch to include the latest changes.  I've also made
a few other tweaks:

* Time tracks are now used with midi playback.  This works in most
cases, but there's a very weird bug where when you _only_ have note
tracks and no audio tracks, the cursor desyncs (it goes at 1 over the
expected speed, so for 200% on the time track, the cursor visually
moves at 50% although playback occurs at 200%).  This doesn't happen
if there's an audio track present, even if it's empty.  I'm currently
not sure why that's happening; probably something simple though.
* Compiling with USE_MIDI disabled now works (it's broken in master
and has been for a while)
* Separate defines for the midi channel toggle buttons and midi
output, so that one can be enabled without the other (includes
handling positioning)
* Right-clicking the mute/solo button on note tracks no longer breaks things

One thing that isn't quite finished: scrubbing.  It just doesn't play
notes most of the time, and isn't enabled unless there's also an audio
track.  I'm not completely sure how scrubbing works; it may be
possible for me to figure it out.

As with before, my development branch is at
https://github.com/pokechu22/audacity/tree/fix-midi-output.

--Poke

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Stevethefiddle
I tried building this on Linux (Ubuntu 16.04 64-bit) but unfortunately
didn't get very far. I'm hitting loads of problems with PortMidi. I
couldn't get Audacity to build with the system library, and I couldn't
get the local library to build.

Steve

On 21 March 2017 at 04:51, Pokechu22 <[hidden email]> wrote:

> I've rebased my branch to include the latest changes.  I've also made
> a few other tweaks:
>
> * Time tracks are now used with midi playback.  This works in most
> cases, but there's a very weird bug where when you _only_ have note
> tracks and no audio tracks, the cursor desyncs (it goes at 1 over the
> expected speed, so for 200% on the time track, the cursor visually
> moves at 50% although playback occurs at 200%).  This doesn't happen
> if there's an audio track present, even if it's empty.  I'm currently
> not sure why that's happening; probably something simple though.
> * Compiling with USE_MIDI disabled now works (it's broken in master
> and has been for a while)
> * Separate defines for the midi channel toggle buttons and midi
> output, so that one can be enabled without the other (includes
> handling positioning)
> * Right-clicking the mute/solo button on note tracks no longer breaks things
>
> One thing that isn't quite finished: scrubbing.  It just doesn't play
> notes most of the time, and isn't enabled unless there's also an audio
> track.  I'm not completely sure how scrubbing works; it may be
> possible for me to figure it out.
>
> As with before, my development branch is at
> https://github.com/pokechu22/audacity/tree/fix-midi-output.
>
> --Poke
>
> ------------------------------------------------------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Paul Licameli
I'm the one who knows scrubbing best.

I made changes earlier so that EXPERIMENTAL_MIDI_OUT would compile again, but it did not link, at least on macOS.  Have you done anything to fix that?

One thing I want to accomplish this release is the track panel refactoring, which is a major reorganization, and if one of us pushes first, the other will have some difficulties merging, but I hope not too great.

PRL


On Tue, Mar 21, 2017 at 8:43 AM, Steve the Fiddle <[hidden email]> wrote:
I tried building this on Linux (Ubuntu 16.04 64-bit) but unfortunately
didn't get very far. I'm hitting loads of problems with PortMidi. I
couldn't get Audacity to build with the system library, and I couldn't
get the local library to build.

Steve

On 21 March 2017 at 04:51, Pokechu22 <[hidden email]> wrote:
> I've rebased my branch to include the latest changes.  I've also made
> a few other tweaks:
>
> * Time tracks are now used with midi playback.  This works in most
> cases, but there's a very weird bug where when you _only_ have note
> tracks and no audio tracks, the cursor desyncs (it goes at 1 over the
> expected speed, so for 200% on the time track, the cursor visually
> moves at 50% although playback occurs at 200%).  This doesn't happen
> if there's an audio track present, even if it's empty.  I'm currently
> not sure why that's happening; probably something simple though.
> * Compiling with USE_MIDI disabled now works (it's broken in master
> and has been for a while)
> * Separate defines for the midi channel toggle buttons and midi
> output, so that one can be enabled without the other (includes
> handling positioning)
> * Right-clicking the mute/solo button on note tracks no longer breaks things
>
> One thing that isn't quite finished: scrubbing.  It just doesn't play
> notes most of the time, and isn't enabled unless there's also an audio
> track.  I'm not completely sure how scrubbing works; it may be
> possible for me to figure it out.
>
> As with before, my development branch is at
> https://github.com/pokechu22/audacity/tree/fix-midi-output.
>
> --Poke
>
> ------------------------------------------------------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Pokechu22-2
On 21 March 2017 at 12:43, Steve the Fiddle <stevethefiddle@gm...> wrote:
> I tried building this on Linux (Ubuntu 16.04 64-bit) but unfortunately
> didn't get very far. I'm hitting loads of problems with PortMidi. I
> couldn't get Audacity to build with the system library, and I couldn't
> get the local library to build.
>
> Steve

I've run into that too, when trying to compile on my Pi.  I think that
the buildscript may be set up incorrectly, but I don't know for sure.
I managed to get it to link somehow, once, but it's not reliable.
I don't know anything about makefiles, so I can't fix it right now.

I can't find any reference to 'PortMidi' within any of the build scripts,
which seems like a bad sign (maybe it's just not included at all?)

It does work on Windows (using Visual Studio), though.

On 21 March 2017 at 13:21, Paul Licameli <paul.licameli@gm...> wrote:
> I made changes earlier so that EXPERIMENTAL_MIDI_OUT would compile again,
> but it did not link, at least on macOS.  Have you done anything to fix that?
>
> One thing I want to accomplish this release is the track panel refactoring,
> which is a major reorganization, and if one of us pushes first, the other
> will have some difficulties merging, but I hope not too great.
>
> PRL

The linking failure was mostly due to EXPERIMENTAL_MIDI_OUT using the older
GainSlider(int) method (back when an array of sliders was allocated); since
that method no longer exists, it fails (but the method was still declared
when EXPERIMENTAL_MIDI_OUT was defined).  I've fixed that by creating a
dedicated velocity slider that works the same way the gain slider works.
That also gets rid of the need to change the style of a slider, and generally
makes things a lot less messy.

There are still link errors related to libraries (which don't happen on
Windows, and I'm not sure how to fix), but none on the actual code within
Audacity.

If you're going to refactor further, that's fine; however, I've been writing
my code in the same style as the current track panel code, so it might make
sense to refactor my code too (though it depends on how the refactoring will
be done).  Conflicts shouldn't be too much of an issue, though (I can resolve
them if needed - some of the existing changes actually caused conflicts but
they weren't too hard to fix).

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Paul Licameli


On Tue, Mar 21, 2017 at 11:36 AM, Pokechu22 <[hidden email]> wrote:
On 21 March 2017 at 12:43, Steve the Fiddle <stevethefiddle@gm...> wrote:
> I tried building this on Linux (Ubuntu 16.04 64-bit) but unfortunately
> didn't get very far. I'm hitting loads of problems with PortMidi. I
> couldn't get Audacity to build with the system library, and I couldn't
> get the local library to build.
>
> Steve

I've run into that too, when trying to compile on my Pi.  I think that
the buildscript may be set up incorrectly, but I don't know for sure.
I managed to get it to link somehow, once, but it's not reliable.
I don't know anything about makefiles, so I can't fix it right now.

I can't find any reference to 'PortMidi' within any of the build scripts,
which seems like a bad sign (maybe it's just not included at all?)

It does work on Windows (using Visual Studio), though.

On 21 March 2017 at 13:21, Paul Licameli <paul.licameli@gm...> wrote:
> I made changes earlier so that EXPERIMENTAL_MIDI_OUT would compile again,
> but it did not link, at least on macOS.  Have you done anything to fix that?
>
> One thing I want to accomplish this release is the track panel refactoring,
> which is a major reorganization, and if one of us pushes first, the other
> will have some difficulties merging, but I hope not too great.
>
> PRL

The linking failure was mostly due to EXPERIMENTAL_MIDI_OUT using the older
GainSlider(int) method (back when an array of sliders was allocated); since
that method no longer exists, it fails (but the method was still declared
when EXPERIMENTAL_MIDI_OUT was defined).  I've fixed that by creating a
dedicated velocity slider that works the same way the gain slider works.
That also gets rid of the need to change the style of a slider, and generally
makes things a lot less messy.

There are still link errors related to libraries (which don't happen on
Windows, and I'm not sure how to fix), but none on the actual code within
Audacity.

If you're going to refactor further, that's fine; however, I've been writing
my code in the same style as the current track panel code, so it might make
sense to refactor my code too (though it depends on how the refactoring will
be done).  Conflicts shouldn't be too much of an issue, though (I can resolve
them if needed - some of the existing changes actually caused conflicts but
they weren't too hard to fix).

TrackPanel.cpp is just to darn big and does too many things.

My reorganization will move many things out into smaller files, and put them behind virtual function interfaces.

You can look at my branch track-panel-refactor to see what the end result will be like.

My more immediate priority is the another big project of adding exception safety for errors reading and writing block files.

PRL

 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Pokechu22-2
On 21 March 2017 at 15:49, Paul Licameli <paul.licameli@gm...> wrote:

> On Tue, Mar 21, 2017 at 11:36 AM, Pokechu22 <pokechu022@...> wrote:
>
> > On 21 March 2017 at 13:21, Paul Licameli <paul.licameli@...> wrote:
> > > I made changes earlier so that EXPERIMENTAL_MIDI_OUT would compile again,
> > > but it did not link, at least on macOS.  Have you done anything to fix
> > that?
> > >
> > > One thing I want to accomplish this release is the track panel
> > refactoring,
> > > which is a major reorganization, and if one of us pushes first, the other
> > > will have some difficulties merging, but I hope not too great.
> > >
> > > PRL
> >
> > The linking failure was mostly due to EXPERIMENTAL_MIDI_OUT using the older
> > GainSlider(int) method (back when an array of sliders was allocated); since
> > that method no longer exists, it fails (but the method was still declared
> > when EXPERIMENTAL_MIDI_OUT was defined).  I've fixed that by creating a
> > dedicated velocity slider that works the same way the gain slider works.
> > That also gets rid of the need to change the style of a slider, and
> > generally
> > makes things a lot less messy.
> >
> > There are still link errors related to libraries (which don't happen on
> > Windows, and I'm not sure how to fix), but none on the actual code within
> > Audacity.
> >
> > If you're going to refactor further, that's fine; however, I've been
> > writing
> > my code in the same style as the current track panel code, so it might make
> > sense to refactor my code too (though it depends on how the refactoring
> > will
> > be done).  Conflicts shouldn't be too much of an issue, though (I can
> > resolve
> > them if needed - some of the existing changes actually caused conflicts but
> > they weren't too hard to fix).
> >
>
> TrackPanel.cpp is just to darn big and does too many things.
>
> My reorganization will move many things out into smaller files, and put
> them behind virtual function interfaces.
>
> You can look at my branch track-panel-refactor to see what the end result
> will be like.
>
> My more immediate priority is the another big project of adding exception
> safety for errors reading and writing block files.
>
> PRL

Hm, looking over that, probably the midi changes should happen first.
I'm already splitting some of the midi code out of the wave track
code, and making the wave track code more general in other cases -
changes that would influence the structure of your refactor.

I like the general idea, and the note-track UI can definitely be moved
to a more sane location. Most of it is still in TrackPanel, but a bit
of it is currently in NoteTrack itself.

So, probably the midi changes should come first.

--Poke

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Paul Licameli


On Tue, Mar 21, 2017 at 4:19 PM, Pokechu22 <[hidden email]> wrote:
On 21 March 2017 at 15:49, Paul Licameli <paul.licameli@gm...> wrote:
> On Tue, Mar 21, 2017 at 11:36 AM, Pokechu22 <pokechu022@...> wrote:
>
> > On 21 March 2017 at 13:21, Paul Licameli <paul.licameli@...> wrote:
> > > I made changes earlier so that EXPERIMENTAL_MIDI_OUT would compile again,
> > > but it did not link, at least on macOS.  Have you done anything to fix
> > that?
> > >
> > > One thing I want to accomplish this release is the track panel
> > refactoring,
> > > which is a major reorganization, and if one of us pushes first, the other
> > > will have some difficulties merging, but I hope not too great.
> > >
> > > PRL
> >
> > The linking failure was mostly due to EXPERIMENTAL_MIDI_OUT using the older
> > GainSlider(int) method (back when an array of sliders was allocated); since
> > that method no longer exists, it fails (but the method was still declared
> > when EXPERIMENTAL_MIDI_OUT was defined).  I've fixed that by creating a
> > dedicated velocity slider that works the same way the gain slider works.
> > That also gets rid of the need to change the style of a slider, and
> > generally
> > makes things a lot less messy.
> >
> > There are still link errors related to libraries (which don't happen on
> > Windows, and I'm not sure how to fix), but none on the actual code within
> > Audacity.
> >
> > If you're going to refactor further, that's fine; however, I've been
> > writing
> > my code in the same style as the current track panel code, so it might make
> > sense to refactor my code too (though it depends on how the refactoring
> > will
> > be done).  Conflicts shouldn't be too much of an issue, though (I can
> > resolve
> > them if needed - some of the existing changes actually caused conflicts but
> > they weren't too hard to fix).
> >
>
> TrackPanel.cpp is just to darn big and does too many things.
>
> My reorganization will move many things out into smaller files, and put
> them behind virtual function interfaces.
>
> You can look at my branch track-panel-refactor to see what the end result
> will be like.
>
> My more immediate priority is the another big project of adding exception
> safety for errors reading and writing block files.
>
> PRL

Hm, looking over that, probably the midi changes should happen first.
I'm already splitting some of the midi code out of the wave track
code, and making the wave track code more general in other cases -
changes that would influence the structure of your refactor.

I am not persuaded.  Explain more specifically what the "structure of my refactor" cannot now accommodate in your changes.

The purpose of this refactor is to have click-drag-release actions all delegated through a virtual function interface to other classes.
 

I like the general idea, and the note-track UI can definitely be moved
to a more sane location. Most of it is still in TrackPanel, but a bit
of it is currently in NoteTrack itself.

So, probably the midi changes should come first.

I do not agree.

My project is a very long overdue refactoring that removes obstacles to other future developments.  It has been waiting very long for merge.  It does not by itself make new functionality, so it will not have serious implications for documentation or testing.

The MIDI playback is not now a certainty for version 2.2.0.  It should be made available in its own fork for the rest of the team to test.  Do we know yet that everything will work, including scrubbing?

I say base your fork on the latest master for which it merges easily.  I will help you rebase that fork onto my changes if need be.  I do not intend to delay my changes on account of MIDI playback.

PRL

 

--Poke

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

James Crook
I'm very much in favour of both TrackPanel refactor and EXPERIMENTAL_MIDI_OUT.

Paul has, well earned, commit rights AND TrackPanel refactor is one of the biggest most important structural changes.  So I think it has to get precedence.  If Paul is willing to help with rebasing/merging the EXPERIMENTAL_MIDI_OUT fixes too, that has got to be the best solution. 

I think the decision on EXPERIMENTAL_MIDI_OUT in 2.2.0 will likely come down to whether the branch works on Mac and Linux as well as Windows.  So that work needs to be done anyway before EXPERIMENTAL_MIDI_OUT is ready to merge into main.  TrackPanel refactor is practically ready right now.

--James.


On 3/21/2017 8:48 PM, Paul Licameli wrote:
On Tue, Mar 21, 2017 at 4:19 PM, Pokechu22 [hidden email] wrote:

On 21 March 2017 at 15:49, Paul Licameli [hidden email] wrote:
On Tue, Mar 21, 2017 at 11:36 AM, Pokechu22 [hidden email] wrote:

On 21 March 2017 at 13:21, Paul Licameli [hidden email] wrote:
I made changes earlier so that EXPERIMENTAL_MIDI_OUT would compile
again,
but it did not link, at least on macOS.  Have you done anything to
fix
that?
One thing I want to accomplish this release is the track panel
refactoring,
which is a major reorganization, and if one of us pushes first, the
other
will have some difficulties merging, but I hope not too great.

PRL
The linking failure was mostly due to EXPERIMENTAL_MIDI_OUT using the
older
GainSlider(int) method (back when an array of sliders was allocated);
since
that method no longer exists, it fails (but the method was still
declared
when EXPERIMENTAL_MIDI_OUT was defined).  I've fixed that by creating a
dedicated velocity slider that works the same way the gain slider
works.
That also gets rid of the need to change the style of a slider, and
generally
makes things a lot less messy.

There are still link errors related to libraries (which don't happen on
Windows, and I'm not sure how to fix), but none on the actual code
within
Audacity.

If you're going to refactor further, that's fine; however, I've been
writing
my code in the same style as the current track panel code, so it might
make
sense to refactor my code too (though it depends on how the refactoring
will
be done).  Conflicts shouldn't be too much of an issue, though (I can
resolve
them if needed - some of the existing changes actually caused
conflicts but
they weren't too hard to fix).

TrackPanel.cpp is just to darn big and does too many things.

My reorganization will move many things out into smaller files, and put
them behind virtual function interfaces.

You can look at my branch track-panel-refactor to see what the end result
will be like.

My more immediate priority is the another big project of adding exception
safety for errors reading and writing block files.

PRL
Hm, looking over that, probably the midi changes should happen first.
I'm already splitting some of the midi code out of the wave track
code, and making the wave track code more general in other cases -
changes that would influence the structure of your refactor.

I am not persuaded.  Explain more specifically what the "structure of my
refactor" cannot now accommodate in your changes.

The purpose of this refactor is to have click-drag-release actions all
delegated through a virtual function interface to other classes.


I like the general idea, and the note-track UI can definitely be moved
to a more sane location. Most of it is still in TrackPanel, but a bit
of it is currently in NoteTrack itself.

So, probably the midi changes should come first.

I do not agree.

My project is a very long overdue refactoring that removes obstacles to
other future developments.  It has been waiting very long for merge.  It
does not by itself make new functionality, so it will not have serious
implications for documentation or testing.

The MIDI playback is not now a certainty for version 2.2.0.  It should be
made available in its own fork for the rest of the team to test.  Do we
know yet that everything will work, including scrubbing?

I say base your fork on the latest master for which it merges easily.  I
will help you rebase that fork onto my changes if need be.  I do not intend
to delay my changes on account of MIDI playback.

PRL



--Poke

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Paul Licameli


On Tue, Mar 21, 2017 at 6:18 PM, James Crook <[hidden email]> wrote:
I'm very much in favour of both TrackPanel refactor and EXPERIMENTAL_MIDI_OUT.

Paul has, well earned, commit rights AND TrackPanel refactor is one of the biggest most important structural changes.  So I think it has to get precedence.  If Paul is willing to help with rebasing/merging the EXPERIMENTAL_MIDI_OUT fixes too, that has got to be the best solution. 

I think the decision on EXPERIMENTAL_MIDI_OUT in 2.2.0 will likely come down to whether the branch works on Mac and Linux as well as Windows.  So that work needs to be done anyway before EXPERIMENTAL_MIDI_OUT is ready to merge into main.  TrackPanel refactor is practically ready right now.

Thanks, James.

I looked again at Pokechu's branch, and rebasing it onto my track-panel-refactor is not so big a problem as I feared, unless there are more changes in store that I have not seen.

PRL

 


--James.



On 3/21/2017 8:48 PM, Paul Licameli wrote:
On Tue, Mar 21, 2017 at 4:19 PM, Pokechu22 [hidden email] wrote:

On 21 March 2017 at 15:49, Paul Licameli [hidden email] wrote:
On Tue, Mar 21, 2017 at 11:36 AM, Pokechu22 [hidden email] wrote:

On 21 March 2017 at 13:21, Paul Licameli [hidden email] wrote:
I made changes earlier so that EXPERIMENTAL_MIDI_OUT would compile
again,
but it did not link, at least on macOS.  Have you done anything to
fix
that?
One thing I want to accomplish this release is the track panel
refactoring,
which is a major reorganization, and if one of us pushes first, the
other
will have some difficulties merging, but I hope not too great.

PRL
The linking failure was mostly due to EXPERIMENTAL_MIDI_OUT using the
older
GainSlider(int) method (back when an array of sliders was allocated);
since
that method no longer exists, it fails (but the method was still
declared
when EXPERIMENTAL_MIDI_OUT was defined).  I've fixed that by creating a
dedicated velocity slider that works the same way the gain slider
works.
That also gets rid of the need to change the style of a slider, and
generally
makes things a lot less messy.

There are still link errors related to libraries (which don't happen on
Windows, and I'm not sure how to fix), but none on the actual code
within
Audacity.

If you're going to refactor further, that's fine; however, I've been
writing
my code in the same style as the current track panel code, so it might
make
sense to refactor my code too (though it depends on how the refactoring
will
be done).  Conflicts shouldn't be too much of an issue, though (I can
resolve
them if needed - some of the existing changes actually caused
conflicts but
they weren't too hard to fix).

TrackPanel.cpp is just to darn big and does too many things.

My reorganization will move many things out into smaller files, and put
them behind virtual function interfaces.

You can look at my branch track-panel-refactor to see what the end result
will be like.

My more immediate priority is the another big project of adding exception
safety for errors reading and writing block files.

PRL
Hm, looking over that, probably the midi changes should happen first.
I'm already splitting some of the midi code out of the wave track
code, and making the wave track code more general in other cases -
changes that would influence the structure of your refactor.

I am not persuaded.  Explain more specifically what the "structure of my
refactor" cannot now accommodate in your changes.

The purpose of this refactor is to have click-drag-release actions all
delegated through a virtual function interface to other classes.


I like the general idea, and the note-track UI can definitely be moved
to a more sane location. Most of it is still in TrackPanel, but a bit
of it is currently in NoteTrack itself.

So, probably the midi changes should come first.

I do not agree.

My project is a very long overdue refactoring that removes obstacles to
other future developments.  It has been waiting very long for merge.  It
does not by itself make new functionality, so it will not have serious
implications for documentation or testing.

The MIDI playback is not now a certainty for version 2.2.0.  It should be
made available in its own fork for the rest of the team to test.  Do we
know yet that everything will work, including scrubbing?

I say base your fork on the latest master for which it merges easily.  I
will help you rebase that fork onto my changes if need be.  I do not intend
to delay my changes on account of MIDI playback.

PRL



--Poke

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Pokechu22-2
In reply to this post by Paul Licameli
I'm sorry, I just wasn't clear.

Apart from fixing EXPERIMENTAL_MIDI_OUT compilation-wise, I cleaned up
a few ugly hacks with it.  _That_ cleanup is what I viewed as a
prerequisite to your changes (since preserving those hacks for later
midi support creates more work).  But probably it won't be as big of
an issue as I made it seem, and probably not something that should
determine the orders they are merged in.  The actual midi changes
definitely aren't a prerequisite.

The potentially hard part is making my changes use the same techniques
as PRL's changes, which probably isn't actually that hard.  That's
what I was referring to initially, and I take that point back on
further consideration.  Sorry for the confusion.

--Poke

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Pokechu22
In reply to this post by Paul Licameli
On Tue, Mar 21, 2017 at 1:48 PM, Paul Licameli <[hidden email]> wrote:
> I am not persuaded.  Explain more specifically what the "structure of my
> refactor" cannot now accommodate in your changes.
>
> The purpose of this refactor is to have click-drag-release actions all
> delegated through a virtual function interface to other classes.

I just tried to apply the EXPERIMENTAL_MIDI_OUT changes to the track
panel refactor.  I return to my original point: it isn't that simple
to apply it (though it's also not that they're incompatible); there's
a number of issues with the way it's set up that make it hard:

1. Mute/Solo buttons need to be accessible to both wave AND note
tracks.  The refactor puts them exclusively as a property of wave
tracks (wavetrack/ui/WaveTrackButtonHandles); it should be more
general (perhaps ui/MuteSoloButtonHandles).  (Additionally, there are
checks that it's a wave track within, but those can manually be
changed).  Note that the position of the mute/solo rect changes by the
track type too; this makes things slightly complicated.  Doing this
cleanly may be difficult.

2. Note tracks have a velocity slider (which works similarly to the
gain slider on wave tracks).  The refactor is incompatible with this;
it assumes that the only type of track that has  a slider is a wave
track (mpTrack is assumed to be a WaveTrack in ui/SliderHandle).

3. A lot of EXPERIMENTAL_MIDI_OUT ui code was put into
wavetrack/ui/WaveTrackSliderHandles; this is probably because the code
was originally mixed together anyways, but it creates a pretty big
mess.  (That is what I was originally thinking of when I said my
changes should come first - I separated out that code and made a
dedicated slider, which would mean that only wave track code would
need to be there, and note track code could be in its own place).

4. In several places, EXPERIMENTAL flags are used without properly
including experimental.h.  This mainly affects EXPERIMENTAL_MIDI_OUT,
but also happens (for example) with EXPERIMENTAL_OUTPUT_DISPLAY in
WaveTrackControls.  In some cases it also is included, but in a
situation where USE_MIDI hasn't been defined yet, causing
EXPERIMENTAL_MIDI_OUT to not be disabled.

None of these are issues with the idea behind it; it's mainly just a
few details in the way you implemented it, and also a case of starting
with base code that isn't well organized.

I've attempted this and gotten everything to mostly work:
https://github.com/pokechu22/audacity/tree/fix-midi-output-plus-tpr.
(The big changes needed to make everything possible are in
https://github.com/pokechu22/audacity/commit/faea5b8). There are still
some issues (particularly with note track controls); this is more to
show what needs to be done to merge it than to actually fully merge
it.

On a side note, your code crashes when audacity is not focused due to
an access violation in HandleCursor.  That makes it somewhat annoying
to test.  There's a few other bugs, too (for instance, dragging most
things makes the close button look like it's being pressed, and
clicking on a slider doesn't set its value).  Maybe it's just an issue
within visual studio, but I don't think it's quite ready yet.

-----

Regarding linux/mac building: all that I _think_ needs to be done is
adding PortMidi to the needed makefiles.  However, I know next to
nothing about automake, and my attempts to add it haven't been
successful.  Some pointers on how to do this would be helpful.
--Poke

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fixing EXPERIMENTAL_MIDI_OUT

Paul Licameli
Have you kept a version not rebased onto track-panel-refactor?

I repeat, I think it is best that you rebase your work instead onto the latest master for which you can, and let the rest of the team experiment with it first.

PRL


On Sun, Mar 26, 2017 at 2:18 AM, Pokechu22 <[hidden email]> wrote:
On Tue, Mar 21, 2017 at 1:48 PM, Paul Licameli <[hidden email]> wrote:
> I am not persuaded.  Explain more specifically what the "structure of my
> refactor" cannot now accommodate in your changes.
>
> The purpose of this refactor is to have click-drag-release actions all
> delegated through a virtual function interface to other classes.

I just tried to apply the EXPERIMENTAL_MIDI_OUT changes to the track
panel refactor.  I return to my original point: it isn't that simple
to apply it (though it's also not that they're incompatible); there's
a number of issues with the way it's set up that make it hard:

1. Mute/Solo buttons need to be accessible to both wave AND note
tracks.  The refactor puts them exclusively as a property of wave
tracks (wavetrack/ui/WaveTrackButtonHandles); it should be more
general (perhaps ui/MuteSoloButtonHandles).  (Additionally, there are
checks that it's a wave track within, but those can manually be
changed).  Note that the position of the mute/solo rect changes by the
track type too; this makes things slightly complicated.  Doing this
cleanly may be difficult.

2. Note tracks have a velocity slider (which works similarly to the
gain slider on wave tracks).  The refactor is incompatible with this;
it assumes that the only type of track that has  a slider is a wave
track (mpTrack is assumed to be a WaveTrack in ui/SliderHandle).

3. A lot of EXPERIMENTAL_MIDI_OUT ui code was put into
wavetrack/ui/WaveTrackSliderHandles; this is probably because the code
was originally mixed together anyways, but it creates a pretty big
mess.  (That is what I was originally thinking of when I said my
changes should come first - I separated out that code and made a
dedicated slider, which would mean that only wave track code would
need to be there, and note track code could be in its own place).

4. In several places, EXPERIMENTAL flags are used without properly
including experimental.h.  This mainly affects EXPERIMENTAL_MIDI_OUT,
but also happens (for example) with EXPERIMENTAL_OUTPUT_DISPLAY in
WaveTrackControls.  In some cases it also is included, but in a
situation where USE_MIDI hasn't been defined yet, causing
EXPERIMENTAL_MIDI_OUT to not be disabled.

None of these are issues with the idea behind it; it's mainly just a
few details in the way you implemented it, and also a case of starting
with base code that isn't well organized.

I've attempted this and gotten everything to mostly work:
https://github.com/pokechu22/audacity/tree/fix-midi-output-plus-tpr.
(The big changes needed to make everything possible are in
https://github.com/pokechu22/audacity/commit/faea5b8). There are still
some issues (particularly with note track controls); this is more to
show what needs to be done to merge it than to actually fully merge
it.

On a side note, your code crashes when audacity is not focused due to
an access violation in HandleCursor.  That makes it somewhat annoying
to test.  There's a few other bugs, too (for instance, dragging most
things makes the close button look like it's being pressed, and
clicking on a slider doesn't set its value).  Maybe it's just an issue
within visual studio, but I don't think it's quite ready yet.

-----

Regarding linux/mac building: all that I _think_ needs to be done is
adding PortMidi to the needed makefiles.  However, I know next to
nothing about automake, and my attempts to add it haven't been
successful.  Some pointers on how to do this would be helpful.
--Poke

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
12
Loading...