From: Tim E. R. <ter...@ro...> - 2011-12-28 09:20:08
|
Howdy. Just to let you guys know what's going on. Some undo/redo crashes fixed - edit track name doesn't crash now. Track name edit box and channel spinbox work properly now (esc key, double click left button only, hide upon focus loss). More importantly, I have eliminated all sort of 'change track' usage, including SEQM_CHANGE_TRACK, msgChangeTrack, Song::changeTrack(), and UndoOp::ModifyTrack. I am convinced now that it was not necessary. The undo/redo stuff was whacked - copying a whole track and using UndoOp::ModifyTrack just for the simplest of things like renaming a track or setting the channel. Reasoning: CANNOT have a TRUE copy of a track (to be put into an undo/redo list or whatever) UNLESS every last detail is copied over - including ladspa plugins, all audio controller values etc. This is impractical. So I have replaced all that with simpler, specific operations like UndoOp::ModifyTrackName and UndoOp::ModifyTrackChannel. The results can be seen in the fixed track name popup edit box and track channel popup spin box and the associated undo/redo. Speaking of whacked, our Track copy constructors were messed up. And I eliminated the Track::operator=. TODO: A few track types still need special care when cloning over (Aux). So.... The progress here can be seen in a *new* Edit menu action: "Duplicate Selected Tracks". This should be a real time saver for setting up multiple 'takes' tracks. *Please* bear with me, it's not complete yet. Few more things to do. Will add dialog: "How many copies?" "Copy plugins?" "Controllers?" etc... I've tested the undo/redo and it seems more solid now. Except for some existing Global operations crashes, like 'Global Cut'. (There's a NULL Marker in there, it crashes. I can try to fix for you.) --- There /is/ one other issue I'd like to point out, perhaps Flo has already mentioned or seen this: We need to refine the undo/redo system to allow /some/ *open* ended adjustments, for example with the track list channel mid- and right-click up/down adjusters. I will likely *not* add that at this time unless I can quickly do a miracle. But I worked out some plans for later, they make /some/ sense so far. Thanks for your patience. Will clean up all comments/markers later. Tim. |
From: Tim E. R. <ter...@ro...> - 2011-12-30 07:29:58
|
And some pics: Dialog: Here I've selected one midi track and one wave track, and opened the 'duplicate track' dialog: http://dl.dropbox.com/u/53315356/duplicate_tracks.jpeg After execution: Here is the result, all track properties (and in this case I selected audio controllers too), are copied, and auto-named slightly different than a brand new track would be (notice it starts at #2 not 1): http://dl.dropbox.com/u/53315356/duplicate_tracks_after.jpeg Tim. |
From: Robert J. <spa...@gm...> - 2011-12-30 09:25:38
|
Hey man! 2011/12/30 Tim E. Real <ter...@ro...>: > And some pics: > > Dialog: > Here I've selected one midi track and one wave track, and opened > the 'duplicate track' dialog: > > http://dl.dropbox.com/u/53315356/duplicate_tracks.jpeg > > After execution: > Here is the result, all track properties (and in this case I selected > audio controllers too), are copied, and auto-named slightly different > than a brand new track would be (notice it starts at #2 not 1): > > http://dl.dropbox.com/u/53315356/duplicate_tracks_after.jpeg Looks like some great stuff! Will be testing. /Robert |
From: Tim E. R. <ter...@ro...> - 2011-12-30 08:16:59
|
On December 30, 2011 2:28:47 AM Tim E. Real wrote: > And some pics: > > Dialog: > Here I've selected one midi track and one wave track, and opened > the 'duplicate track' dialog: > > http://dl.dropbox.com/u/53315356/duplicate_tracks.jpeg > > After execution: > Here is the result, all track properties (and in this case I selected > audio controllers too), are copied, and auto-named slightly different > than a brand new track would be (notice it starts at #2 not 1): > > http://dl.dropbox.com/u/53315356/duplicate_tracks_after.jpeg > Committed to release_2_0 branch. Try it out! Florian, I had to alter the copy constructors of class Track and some descendants. Wary of similarities and redundancies between 'copy' constructors and 'assignment' operators or methods, and knowing sometimes we really don't want /everything/ copied over, I added a convenient new method to Track and 2 of the descendants MidiTrack + AudioTrack: Track::assign(const Track& t, int flags) The copy constructors now also take the same flags parameter. So now our copy constructors and the new assign method are /selective/. So we now have /two/ ways to copy a track: The copy constructors, or 'new' + assign(). I've tested usage of both methods extensively using a handy code switch in song.cpp : Song::duplicateTracks(): You can too, if you want to see the difference. There shouldn't be any, but differences may have crept in, bugs etc. I hope merging isn't a hassle. It's cleaned up now. Flo: The clone parts reference counting has some how become wrong. When you make a clone, and right-click on it, it now says 'Select 3 clones'. I'll try to investigate, are you aware of any changes to the cloning reference counting system which may have done that? I saw a few places where you weren't sure about the reference counts. (I know, it's a /very/ difficult intricate thing to follow and debug.) Tim. |
From: Tim E. R. <ter...@ro...> - 2011-12-31 08:29:25
|
Here ya go! 'Duplicate tracks' route copying now works, including Audio Input/Output Jack routes. You may get "addRoute: src track route already exists" when say, an audio output and wave track are selected just because of the redundancy (wave track wants to connect to output by default). I think it's benign. Checking... It's fresh so watch for bugs. ---- I don't know about you folks, but this feature will be extremely useful next time I record, because: It's time for that guitar solo: -------------------------------- Previous: ---------- Plan for 3 takes. Set up 3 wave tracks and fiddle and adjust them all three times over so they're identical volume and pan. Record the takes. Rats - I sucked! Need more takes! Set up 2 or 3 more wave tracks and fiddle with them while my inspiration melts away. Now: ------ Set up and fiddle with just one wave track. 'Duplicate 3 tracks'... ready! Record the takes. Rats - I sucked! Gimme more takes! 'Duplicate 3 tracks'... ready! Go nuts! Lemme know... Cheers. Tim. |
From: Tim E. R. <ter...@ro...> - 2012-01-04 00:53:43
|
On January 3, 2012 8:14:26 PM Florian Jung wrote: > Am 30.12.2011 09:16, schrieb Tim E. Real: > > Florian, I had to alter the copy constructors of class Track and some > > > > descendants. > > had a look at it, should cause no trouble. > i added ASSIGN_DRUMMAP in experimental for assigning the new-style > drummaps (each track owns one) and extended the dialog accordingly. OK Thanks. I think my part copying option there is still not working correctly. Must check some more. After examining the whole track copying thing and removing wholesale copying of tracks in favour of smaller detailed operations, it occurred to me that wholesale copying of parts just to place into undo/redo lists just because of some small change also seems terribly wrong. I mean duplicating a part just because say the position changed seems over-doing a bit. It especially makes no sense since most of the time the event list is not copied over - the pointer is copied - meaning these full part copying operations are pretty pointless. I won't touch it now because it's working, but I should review the whole thing later at some point. Tim. > > btw: merged :) > > greetings > flo > |
From: Florian J. <flo...@we...> - 2012-01-04 14:10:02
|
Am 04.01.2012 01:53, schrieb Tim E. Real: > On January 3, 2012 8:14:26 PM Florian Jung wrote: > >> Am 30.12.2011 09:16, schrieb Tim E. Real: >> >>> Florian, I had to alter the copy constructors of class Track and some >>> >>> descendants. >>> >> had a look at it, should cause no trouble. >> i added ASSIGN_DRUMMAP in experimental for assigning the new-style >> drummaps (each track owns one) and extended the dialog accordingly. >> > OK Thanks. > > I think my part copying option there is still not working correctly. > Must check some more. > > After examining the whole track copying thing and removing > wholesale copying of tracks in favour of smaller detailed operations, > it occurred to me that wholesale copying of parts just to place into > undo/redo lists just because of some small change also seems > terribly wrong. > I mean duplicating a part just because say the position changed > seems over-doing a bit. > It especially makes no sense since most of the time the event list > is not copied over - the pointer is copied - meaning these full part > copying operations are pretty pointless. > I won't touch it now because it's working, but I should review the > whole thing later at some point. > "if it ain't broken, don't fix it" "premature optimisation is the root of all evil" really, if this doesn't cause any real problems (muse running out of memory, buggy behaviour), then just let it as it's now rather than implementing some more optimal, but complicated mechanism. (in particular: muse using some megs more than it should is NOT a problem. using some hundred megs more can become one.) greetings flo > Tim. > > >> btw: merged :) >> >> greetings >> flo >> >> > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |
From: Florian J. <flo...@we...> - 2011-12-30 18:39:19
|
Am 30.12.2011 09:16, schrieb Tim E. Real: > On December 30, 2011 2:28:47 AM Tim E. Real wrote: > >> And some pics: >> >> Dialog: >> Here I've selected one midi track and one wave track, and opened >> the 'duplicate track' dialog: >> >> http://dl.dropbox.com/u/53315356/duplicate_tracks.jpeg >> >> After execution: >> Here is the result, all track properties (and in this case I selected >> audio controllers too), are copied, and auto-named slightly different >> than a brand new track would be (notice it starts at #2 not 1): >> >> http://dl.dropbox.com/u/53315356/duplicate_tracks_after.jpeg >> >> > Committed to release_2_0 branch. Try it out! > > Florian, I had to alter the copy constructors of class Track and some > descendants. > > Wary of similarities and redundancies between 'copy' constructors > and 'assignment' operators or methods, and knowing sometimes we > really don't want /everything/ copied over, I added a convenient new > method to Track and 2 of the descendants MidiTrack + AudioTrack: > > Track::assign(const Track& t, int flags) > > The copy constructors now also take the same flags parameter. > So now our copy constructors and the new assign method are /selective/. > > So we now have /two/ ways to copy a track: > The copy constructors, or 'new' + assign(). > I've tested usage of both methods extensively using a handy code switch in > song.cpp : Song::duplicateTracks(): > You can too, if you want to see the difference. There shouldn't be any, > but differences may have crept in, bugs etc. > > I hope merging isn't a hassle. It's cleaned up now. > > Flo: The clone parts reference counting has some how become wrong. > When you make a clone, and right-click on it, it now says 'Select 3 clones'. > I'll try to investigate, are you aware of any changes to the cloning > reference counting system which may have done that? > yeah, there was a issue... with my operation groups, copying a part, removing the old and adding the new caused the clone counter to be wrong. reason: copying the part/eventlist set the refcounter to 1. adding the part via operation group increased the counter AGAIN. (wrongly!). solution: before applying that operation group, decrement the refcounter by one. > I saw a few places where you weren't sure about the reference counts. > (I know, it's a /very/ difficult intricate thing to follow and debug.) > then you probably saw the some_event_list->incRefCount(-1); lines. they fixed it... i'll have a look at it as well... which commit introduced the bug? greetings flo > Tim. > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |
From: Tim E. R. <ter...@ro...> - 2012-01-02 07:22:22
|
On December 30, 2011 7:38:55 PM Florian Jung wrote: > Am 30.12.2011 09:16, schrieb Tim E. Real: > > On December 30, 2011 2:28:47 AM Tim E. Real wrote: > > Flo: The clone parts reference counting has some how become wrong. > > When you make a clone, and right-click on it, it now says 'Select 3 > > clones'. I'll try to investigate, are you aware of any changes to the > > cloning> > > reference counting system which may have done that? > > yeah, there was a issue... > with my operation groups, copying a part, removing the old and adding > the new caused the clone counter to be wrong. > reason: copying the part/eventlist set the refcounter to 1. adding the > part via operation group increased the counter AGAIN. (wrongly!). > solution: before applying that operation group, decrement the refcounter > by one. > > > I saw a few places where you weren't sure about the reference counts. > > (I know, it's a /very/ difficult intricate thing to follow and debug.) > > then you probably saw the some_event_list->incRefCount(-1); lines. they > fixed it... > > i'll have a look at it as well... which commit introduced the bug? Fixed. It was the drag and drop cloning parts - bad reference count in PartCanvas::moveItem(). Test OK so far. --- I had a look at your operations groups mechanism. In order to make it work you have a HACK in Song::applyOperationGroup(). It is both a crafty solution and a eyebrow-raising scary one. Good because we needed a way to quickly execute groups of multiple (say, trivial) operations /without/ the waiting each time from msgXXX, yet /still/ respect at least a single synchronization cycle with audio. AFAICT... The hack seems to be just what the doctor ordered. Otherwise we would have had to invent another way, either another system nearly identical to Redo, or a new kind of audio message containing a list of messages - which would likely lead to code redundant with Redo anyway. Scary because not only is it a hack, but anything wishing to use the part operations must artificially play with the eventlist reference counts before passing to applyOperationGroup. 'Collateral damage' further hacks. Redo was not designed for this, per se... I'm still not entirely convinced Redo perfectly matches what /would/ have been executed separately, as already demonstrated by these part operations. I had to step through your sequence several times with various operation scenarios to be sure of what I saw. Still, I can't argue with your reasoning. Else would be a lot of work. After all, our Undo/Redo sequences have always executed everything at once anyway (wait in stage 2), without waiting for each operation. --- The audio engine does have an 'idle' command message. It can be put into idle for intensive operations. Is done in a few places. IIRC when idling none of the intensive audio processing is done although audio messages are still handled, leaving more time for your operations. I believe, benefiting even if all your operations do take place all within one synchronized audio cycle, judging by this ... See at audio.cpp : Audio::process(), at the top. In idle mode it still process messages, but then delivers some simple silence then we're outta there - no further processing. Happy 2012! Tim. |
From: Florian J. <flo...@we...> - 2012-01-03 19:14:42
|
Am 30.12.2011 09:16, schrieb Tim E. Real: > Florian, I had to alter the copy constructors of class Track and some > descendants. > had a look at it, should cause no trouble. i added ASSIGN_DRUMMAP in experimental for assigning the new-style drummaps (each track owns one) and extended the dialog accordingly. btw: merged :) greetings flo |