in/out point selected plugin attach fix?
My initial idea about modifying track.C was wrong, but even simpler mod (attached) makes selection by setting in/out points and attaching plugin from menu work... in sense your plugin legth now can be set by setting i/o points not by just mouse selection or making few cuts with 'x' blade and then selecting block.. Phyllis, Andrea - can you give this patch a lot of testing? I mean with many tracks (armed/disarmed), many plugins, shared plugins, gang modes, etc...?
Andrew, I will test after I fix my multibit mess. BUT, I suspect the problem with GANG mode is going to be broken because that is the fix that went into the June 2020 release. On Thu, Aug 5, 2021 at 11:13 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
My initial idea about modifying track.C was wrong, but even simpler mod (attached) makes selection by setting in/out points and attaching plugin from menu work...
in sense your plugin legth now can be set by setting i/o points not by just mouse selection or making few cuts with 'x' blade and then selecting block..
Phyllis, Andrea - can you give this patch a lot of testing? I mean with many tracks (armed/disarmed), many plugins, shared plugins, gang modes, etc...? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Thursday, August 5, 2021, Phyllis Smith via Cin < [email protected]> wrote:
Andrew, I will test after I fix my multibit mess. BUT, I suspect the problem with GANG mode is going to be broken because that is the fix that went into the June 2020 release.
well, this is not full revert, just calling some function with different (empty) argument.. so I hope it will not reintroduce original bug.
but of course only tests will tell
On Thu, Aug 5, 2021 at 11:13 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
My initial idea about modifying track.C was wrong, but even simpler mod (attached) makes selection by setting in/out points and attaching plugin from menu work...
in sense your plugin legth now can be set by setting i/o points not by just mouse selection or making few cuts with 'x' blade and then selecting block..
Phyllis, Andrea - can you give this patch a lot of testing? I mean with many tracks (armed/disarmed), many plugins, shared plugins, gang modes, etc...? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew, it is not working for me when I apply the patch, but Let me do a full build instead of just compiling mwindowedit.C. On Thu, Aug 5, 2021 at 11:13 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
My initial idea about modifying track.C was wrong, but even simpler mod (attached) makes selection by setting in/out points and attaching plugin from menu work...
in sense your plugin legth now can be set by setting i/o points not by just mouse selection or making few cuts with 'x' blade and then selecting block..
Phyllis, Andrea - can you give this patch a lot of testing? I mean with many tracks (armed/disarmed), many plugins, shared plugins, gang modes, etc...? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Full build did not make a difference. To generate the problem: 1) create new empty project 2) set in and out pointers 3) use "attach effect" on the track (right mouse button) to bring up menu and choose a plugin and press OK You can tell it "thinks" it attached the effect because the patchbay gets bigger but you see nothing. Do the same thing but instead of using in and out points, swipe a section which highlights that area and do 1-3, it works. But it does seem like the patch may be better even though I have no idea. BTW: removing the switches from the x265_3.5.patch3 make lines speeds up the compile so now it only takes twice as long to do a full build -- much better so I checked that change into GIT too. On Thu, Aug 5, 2021 at 8:09 PM Phyllis Smith <[email protected]> wrote:
Andrew, it is not working for me when I apply the patch, but Let me do a full build instead of just compiling mwindowedit.C.
On Thu, Aug 5, 2021 at 11:13 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
My initial idea about modifying track.C was wrong, but even simpler mod (attached) makes selection by setting in/out points and attaching plugin from menu work...
in sense your plugin legth now can be set by setting i/o points not by just mouse selection or making few cuts with 'x' blade and then selecting block..
Phyllis, Andrea - can you give this patch a lot of testing? I mean with many tracks (armed/disarmed), many plugins, shared plugins, gang modes, etc...? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Friday, August 6, 2021, Phyllis Smith via Cin <[email protected]> wrote:
Full build did not make a difference. To generate the problem: 1) create new empty project 2) set in and out pointers 3) use "attach effect" on the track (right mouse button) to bring up menu and choose a plugin and press OK
i used menu from main window - > video - > attach effect guess I missed another similar case (it was not working before and with patch it was working for me)
You can tell it "thinks" it attached the effect because the patchbay gets bigger but you see nothing. Do the same thing but instead of using in and out points, swipe a section which highlights that area and do 1-3, it works.
But it does seem like the patch may be better even though I have no idea.
BTW: removing the switches from the x265_3.5.patch3 make lines speeds up the compile so now it only takes twice as long to do a full build -- much better so I checked that change into GIT too.
On Thu, Aug 5, 2021 at 8:09 PM Phyllis Smith <[email protected]> wrote:
Andrew, it is not working for me when I apply the patch, but Let me do a full build instead of just compiling mwindowedit.C.
On Thu, Aug 5, 2021 at 11:13 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
My initial idea about modifying track.C was wrong, but even simpler mod (attached) makes selection by setting in/out points and attaching plugin from menu work...
in sense your plugin legth now can be set by setting i/o points not by just mouse selection or making few cuts with 'x' blade and then selecting block..
Phyllis, Andrea - can you give this patch a lot of testing? I mean with many tracks (armed/disarmed), many plugins, shared plugins, gang modes, etc...? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I confirm that the patch does not work. The In/Out points do not create a valid region for "attach effect". It works instead, as before, for the Drag&Drop effect from the Resources window.
what about attached second patch? please also test main menu bar > video > atrach effect way.. On Friday, August 6, 2021, Andrea paz <[email protected]> wrote:
I confirm that the patch does not work. The In/Out points do not create a valid region for "attach effect". It works instead, as before, for the Drag&Drop effect from the Resources window.
Also the second patch does not work on my CinGG: neither using RMB + attach effect nor using Video --> attach effect. No messages appear on the terminal.
On Friday, August 6, 2021, Andrea paz <[email protected]> wrote:
Also the second patch does not work on my CinGG: neither using RMB + attach effect nor using Video --> attach effect.
o. O no idea why... can you visually inspect patched files (cinelerra/plugindialog.C and cinelerra/mwindowedit.C) and confirm those calls actually changed? $ cat in_out_selection.diff diff --git a/cinelerra-5.1/cinelerra/mwindowedit.C b/cinelerra-5.1/cinelerra/mwindowedit.C index 6744cee8..458ced96 100644 --- a/cinelerra-5.1/cinelerra/mwindowedit.C +++ b/cinelerra-5.1/cinelerra/mwindowedit.C @@ -841,8 +841,8 @@ void MWindow::insert_effect(char *title, SharedLocation *shared_location, SharedLocation shared_location_local; shared_location_local.copy_from(shared_location); int first_track = 1; - double start_pos = edl->local_session->get_selectionstart(1); - double end_pos = edl->local_session->get_selectionend(1); + double start_pos = edl->local_session->get_selectionstart(); + double end_pos = edl->local_session->get_selectionend(); for( ; current; current=NEXT ) { if( current->data_type != data_type ) continue; if( !current->is_armed() ) continue; $ cat in_out_selection-2.diff diff --git a/cinelerra-5.1/cinelerra/plugindialog.C b/cinelerra-5.1/cinelerra/plugindialog.C index 48f470e6..fa24bb5b 100644 --- a/cinelerra-5.1/cinelerra/plugindialog.C +++ b/cinelerra-5.1/cinelerra/plugindialog.C @@ -463,8 +463,8 @@ void PluginDialogThread::apply() &shared_location, plugin_type); } else if( edl->tracks->track_exists(track) ) { - double start = edl->local_session->get_selectionstart(1); - double end = edl->local_session->get_selectionend(1); + double start = edl->local_session->get_selectionstart(); + double end = edl->local_session->get_selectionend(); if( start >= end ) { start = 0; end = track->get_length(); $ No messages appear on the terminal.
this is normal, this time i did not added any debug printfs)
Andrew, Initial test seemed to work for me BUT not done testing yet. On Fri, Aug 6, 2021 at 10:14 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
what about attached second patch?
please also test main menu bar > video > atrach effect way..
On Friday, August 6, 2021, Andrea paz <[email protected]> wrote:
I confirm that the patch does not work. The In/Out points do not create a valid region for "attach effect". It works instead, as before, for the Drag&Drop effect from the Resources window.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew, more testing of "many tracks (armed/disarmed), many plugins, shared plugins, gang modes, etc...?" and it seems like a really good fix. Will wait to hear back from Andrea too. But there must be one more place that needs the same type of fix yet for GANG audio mode. This is currently working if you drag an audio plugin to a 2-channel audio track - that is, when you get back to regular mode you can see that the plugin is on both audio tracks. But when you have In/Out pointers and use the "attach effect" method instead, it only shows on the initial track. Andrea, you have to have both patches in: in_out_selection.diff AND in_out_selection-2.diff . On Fri, Aug 6, 2021 at 10:14 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
what about attached second patch?
please also test main menu bar > video > atrach effect way..
On Friday, August 6, 2021, Andrea paz <[email protected]> wrote:
I confirm that the patch does not work. The In/Out points do not create a valid region for "attach effect". It works instead, as before, for the Drag&Drop effect from the Resources window.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Saturday, August 7, 2021, Phyllis Smith via Cin < [email protected]> wrote:
Andrew, more testing of "many tracks (armed/disarmed), many plugins, shared plugins, gang modes, etc...?" and it seems like a really good fix. Will wait to hear back from Andrea too.
But there must be one more place that needs the same type of fix yet for GANG audio mode. This is currently working if you drag an audio plugin to a 2-channel audio track - that is, when you get back to regular mode you can see that the plugin is on both audio tracks. But when you have In/Out pointers and use the "attach effect" method instead, it only shows on the initial track.
i tried to add two more lines into mwindowedit.C and for me I can select in/out points for two gang modes where sound tracks collapsed on timeline (with 6ch divx) and then use audio > attach effect for inserting effect and it propagates correctly
Andrea, you have to have both patches in: in_out_selection.diff AND in_out_selection-2.diff .
On Fri, Aug 6, 2021 at 10:14 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
what about attached second patch?
please also test main menu bar > video > atrach effect way..
On Friday, August 6, 2021, Andrea paz <[email protected]> wrote:
I confirm that the patch does not work. The In/Out points do not create a valid region for "attach effect". It works instead, as before, for the Drag&Drop effect from the Resources window.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Saturday, August 7, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Saturday, August 7, 2021, Phyllis Smith via Cin < [email protected]> wrote:
Andrew, more testing of "many tracks (armed/disarmed), many plugins, shared plugins, gang modes, etc...?" and it seems like a really good fix. Will wait to hear back from Andrea too.
But there must be one more place that needs the same type of fix yet for GANG audio mode. This is currently working if you drag an audio plugin to a 2-channel audio track - that is, when you get back to regular mode you can see that the plugin is on both audio tracks. But when you have In/Out pointers and use the "attach effect" method instead, it only shows on the initial track.
i tried to add two more lines into mwindowedit.C
and for me I can select in/out points for two gang modes where sound tracks collapsed on timeline (with 6ch divx) and then use audio > attach effect for inserting effect and it propagates correctly
apoarently this patch was invalid. but I played more with gang modes and effect attach to protected (unarmed) tracks and IMO there was bug If I attach effect in gang mode channels or media it will attach itself to all suitable channels, even unarmed! attached patch fix this, but i haven't tested for example two 6ch audio media on all different tracks..
Andrea, you have to have both patches in: in_out_selection.diff AND in_out_selection-2.diff .
On Fri, Aug 6, 2021 at 10:14 AM Andrew Randrianasulu via Cin < [email protected]> wrote:
what about attached second patch?
please also test main menu bar > video > atrach effect way..
On Friday, August 6, 2021, Andrea paz <[email protected]> wrote:
I confirm that the patch does not work. The In/Out points do not create a valid region for "attach effect". It works instead, as before, for the Drag&Drop effect from the Resources window.
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
As usual, my fault: I had only applied the second patch..... Now I add the 4 patches and it works fine. If I use "Gang Media" (only the master track is visible) and apply a plugin to the master track only, this plugin is not propagated to the slaves tracks, whether armed or not. See image. To the master track the plugin is applied even if the track is unarmed. I think that's right, since "Attach Effect" applies to the affected track only. By Drag&Drop the plugin from the Resource window, this is applied to all armed tracks (whether master or slave) and none of the unarmed ones. I think that's right too.
Other tests: Using Audio --> Attach Effect (con abilitato: "Single standalone and shared others") in "Gang None", the plugin is applied to the first master track only and applied as shared effects to all other armed tracks, whether master or slave. Using Audio --> Attach Effect in "Gang Media" (con abilitato: "Single standalone and shared others"), the plugin is applied only to the first armed master track and as shared effects to the following armed slave tracks. A slave track preceding the first armed master track is not taken into account. Using Audio --> Attach Effect (with unchecked: "Single standalone and shared others") in "Gang None", the plugin is applied to all armed tracks, whether master or slaves. There are no shared effects, only primary plugins. Using Audio --> Attach Effect (with unchecked: "Single standalone and shared others") in "Gang Media", the plugin is applied only to the first armed master track and its slaves. A slave track preceding the first armed master track is not taken into account. There are no shared effects, only primary plugins.
PS: If I'm not mistaken the patch 0004-Attempt-at-fixing-armed-status-while-attaching-plugi.patch leads to a behavior that doesn't agree with what is established in MantisBT#577
On Saturday, August 7, 2021, Andrea paz <[email protected]> wrote:
PS: If I'm not mistaken the patch 0004-Attempt-at-fixing-armed-status-while-attaching-plugi.patch leads to a behavior that doesn't agree with what is established in MantisBT#577
ah, pardon! i thought (incorrectly) armed/disarmed status should be respected in all modes.. i mean I just used those modes as 'advanced track hide', so i armed/disarmed few _audio_ tracks in maximized main window, then set gang mode, and added some plugins assuming they will affect tracks exactly as i ordered before switching gang mode... (because if you insert plugins in gang mode none and whhile all tracks are visible but some disarmed it will only affect armed tracks..). So I aimed for consistency, but guess 'you can' t see them = unaffected" is also possible mode of operation...
I think the best course of action, in line with BT#577, is to use patches 1 and 2, which work fine, and not use 3 and 0004. I remember it being a long discussion to get that result and I wouldn't want to start all over again. Phyllis, what do you think?
On Saturday, August 7, 2021, Andrea paz <[email protected]> wrote:
I think the best course of action, in line with BT#577, is to use patches 1 and 2, which work fine, and not use 3 and 0004. I remember it being a long discussion to get that result and I wouldn't want to start all over again.
In theory I can try to implement some kind of checkbox/toggle between those two modes (named like 'respect armed state in gang modes'), but for now may be patch listing in manul ('if you want to change default behavior just change those lines, like shown here') will be enough..?
Phyllis, what do you think?
On Saturday, August 7, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Saturday, August 7, 2021, Andrea paz <[email protected]> wrote:
I think the best course of action, in line with BT#577, is to use patches 1 and 2, which work fine, and not use 3 and 0004. I remember it being a long discussion to get that result and I wouldn't want to start all over again.
In theory I can try to implement some kind of checkbox/toggle between those two modes (named like 'respect armed state in gang modes'), but for now may be patch listing in manul ('if you want to change default behavior just change those lines, like shown here') will be enough..?
i found mail list discussion, thing is it was initially about _play_ feature, not disarm feature (i see arm/disarm as way to protect tracks from unwanted change..) src: https://lists.cinelerra-gg.org/pipermail/cin/2020-October/002514.html again, I wonder why it was noted by Phyllis "but making it a Preference is not a good idea.". Just because our Preferences a bit crowded already?
Phyllis, what do you think?
On Saturday, August 7, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Saturday, August 7, 2021, Andrew Randrianasulu <[email protected]> wrote:
On Saturday, August 7, 2021, Andrea paz <[email protected]> wrote:
I think the best course of action, in line with BT#577, is to use patches 1 and 2, which work fine, and not use 3 and 0004. I remember it being a long discussion to get that result and I wouldn't want to start all over again.
In theory I can try to implement some kind of checkbox/toggle between those two modes (named like 'respect armed state in gang modes'), but for now may be patch listing in manul ('if you want to change default behavior just change those lines, like shown here') will be enough..?
i found mail list discussion, thing is it was initially about _play_ feature, not disarm feature (i see arm/disarm as way to protect tracks from unwanted change..)
src: https://lists.cinelerra-gg.org/pipermail/cin/2020-October/002514.html
again, I wonder why it was noted by Phyllis "but making it a Preference is not a good idea.". Just because our Preferences a bit crowded already?
anyway, just as with rewind speed I created local variable controlling this behavior, and stored it into Cinelerra_rc (so you can edit it like you want w/o recompilation) see patch 0005
Phyllis, what do you think?
Hi Andrew_R, I have little time to reply here now, but could you read the good Manual, section 5.2.1 (https://cinelerra-gg.org/download/CinelerraGG_Manual.pdf) before make patches and create an other item for Preferences, please? A lot of discussion was made time ago about. I think it is better to speak and then, eventually, make a patch, if possible. Sorry but I am ignorant in Linux, and I don't understand anything about patches. And thanks for your effort. May be tomorrow (sunday) I try to explain better. Thanks. IgorBeg Il 07/08/2021 19:39, Andrew Randrianasulu via Cin ha scritto:
On Saturday, August 7, 2021, Andrew Randrianasulu <[email protected] <mailto:[email protected]>> wrote:
On Saturday, August 7, 2021, Andrew Randrianasulu <[email protected] <mailto:[email protected]>> wrote:
On Saturday, August 7, 2021, Andrea paz <[email protected] <mailto:[email protected]>> wrote:
I think the best course of action, in line with BT#577, is to use patches 1 and 2, which work fine, and not use 3 and 0004. I remember it being a long discussion to get that result and I wouldn't want to start all over again.
In theory I can try to implement some kind of checkbox/toggle between those two modes (named like 'respect armed state in gang modes'), but for now may be patch listing in manul ('if you want to change default behavior just change those lines, like shown here') will be enough..?
i found mail list discussion, thing is it was initially about _play_ feature, not disarm feature (i see arm/disarm as way to protect tracks from unwanted change..)
src: https://lists.cinelerra-gg.org/pipermail/cin/2020-October/002514.html <https://lists.cinelerra-gg.org/pipermail/cin/2020-October/002514.html>
again, I wonder why it was noted by Phyllis "but making it a Preference is not a good idea.". Just because our Preferences a bit crowded already?
anyway, just as with rewind speed I created local variable controlling this behavior, and stored it into Cinelerra_rc (so you can edit it like you want w/o recompilation)
see patch 0005
Phyllis, what do you think?
On Saturday, August 7, 2021, Igor BEGHETTO via Cin < [email protected]> wrote:
Hi Andrew_R, I have little time to reply here now, but could you read the good Manual, section 5.2.1 (https://cinelerra-gg.org/download/CinelerraGG_Manual.pdf) before make patches and create an other item for Preferences, please?
I sure will re-read this section, thanks! just I thought documentation always can be changed/extended if new idea how to get it work both ways can be found. making small changes in codebase is good for my practice, and hopefully recording my mistakes publically will be useful for those who might want to make different changes in CinGG in future (or even for future myself) sorry for surprizing amount of mails on every little subject - have enough time for life!
A lot of discussion was made time ago about. I think it is better to speak and then, eventually, make a patch, if possible. Sorry but I am ignorant in Linux, and I don't understand anything about patches. And thanks for your effort. May be tomorrow (sunday) I try to explain better. Thanks.
IgorBeg
Il 07/08/2021 19:39, Andrew Randrianasulu via Cin ha scritto:
On Saturday, August 7, 2021, Andrew Randrianasulu < [email protected] <mailto:[email protected]>> wrote:
On Saturday, August 7, 2021, Andrew Randrianasulu <[email protected] <mailto:[email protected]>> wrote:
On Saturday, August 7, 2021, Andrea paz <[email protected] <mailto:[email protected]>> wrote:
I think the best course of action, in line with BT#577, is to use patches 1 and 2, which work fine, and not use 3 and 0004. I remember it being a long discussion to get that result and I wouldn't want to start all over again.
In theory I can try to implement some kind of checkbox/toggle between those two modes (named like 'respect armed state in gang modes'), but for now may be patch listing in manul ('if you want to change default behavior just change those lines, like shown here') will be enough..?
i found mail list discussion, thing is it was initially about _play_ feature, not disarm feature (i see arm/disarm as way to protect tracks from unwanted change..)
src: https://lists.cinelerra-gg.org/pipermail/cin/2020-October/002514.html <https://lists.cinelerra-gg.org/pipermail/cin/2020-October/ 002514.html>
again, I wonder why it was noted by Phyllis "but making it a Preference is not a good idea.". Just because our Preferences a bit crowded already?
anyway, just as with rewind speed I created local variable controlling this behavior, and stored it into Cinelerra_rc (so you can edit it like you want w/o recompilation)
see patch 0005
Phyllis, what do you think?
--
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
just I thought documentation always can be changed/extended if new idea how to get it work both ways can be found.
Yes, you are right, but I think that as works GANG modes is correct, and the Manual speaks very well: the NOTES are good to understand better as it works. And like AndreaPAz wrote, your patches 1 and 2 "for in_out_selection" are really good. Thanks, Andrew_R! For the question about using "GANG Channels" and "GANG Media" with Highligh (high priority) and/or In-Out points (low priority) selection to insert an Effect (Plugin): I would write in the Manual that it works with DragAndDrop from the Resources to Timeline. If you are using Menu-> Audio-> Attach Effect..., and you want propagate the effect to its Slave track the "Attach single standalone and share others", in the Dialog window, have to be checked. If you are using RMB on the Master track to add an Effect, only on this track will be inserted the Effect. In this last case could be better changing the behaviour, and share the Effect to its Slave track but I am not sure.
In theory I can try to implement some kind of checkbox/toggle between those two modes (named like 'respect armed state in gang modes'), but for now may be patch listing in manul ('if you want to change default behavior just change those lines, like shown here') will be enough..?
I think it is not a good idea, sorry; it might create more confusion. The GANG modes are very clear and they are written in the Manual. Like me, if you want to use the usual behaviour you use "GANG None" which is the deafult. Thanks and sorry for the long discussion (and sorry for my bad English)! IgorBeg
Yes, you are right, but I think that as works GANG modes is correct, and the Manual speaks very well: the NOTES are good to understand better as it works. And like AndreaPAz wrote, your patches 1 and 2 "for in_out_selection" are really good. Thanks, Andrew_R!
I have checked into GIT in_out_selection.diff and in_out_selection-2.diff since they fixed a bug. Thanks!
For the question about using "GANG Channels" and "GANG Media" with Highligh (high priority) and/or In-Out points (low priority) selection to insert an Effect (Plugin): I would write in the Manual that it works with DragAndDrop from the Resources to Timeline. If you are using Menu-> Audio-> Attach Effect..., and you want propagate the effect to its Slave track the "Attach single standalone and share others", in the Dialog window, have to be checked. If you are using RMB on the Master track to add an Effect, only on this track will be inserted the Effect. In this last case could be better changing the behaviour, and share the Effect to its Slave track but I am not sure.
I have checked into GIT for the manual, the suggestion under NOTES + some clarification as: When adding a Plugin/Effect in Gang Channels or Gang Media mode to the track, highlighted selected region, or In/Out pointers area via dragging the plugin from the Resources Window the plugin will be added on the master and all slave tracks. If using the Audio or Video pulldown, Attach Effect option and you want to propagate the effect to all slave tracks, make sure that the checkbox for "Attach single standalone and share others" in the Dialog window is checked. However, currently when using the right mouse button (RMB) on the master track to Attach effect, the effect will only be inserted on that track. Under "Arm Track" description added (this should be added elsewhere because it appears to be a long-standing policy, but not sure where to put it): Note that disarming a track does not prevent you from dragging or attaching an Effect/Plugin onto a disarmed track - this is not considered an edit for this case.
In theory I can try to implement some kind of checkbox/toggle between those two modes (named like 'respect armed state in gang modes'), but for now may be patch listing in manul ('if you want to change default behavior just change those lines, like shown here') will be enough..?
I think it is not a good idea, sorry; it might create more confusion. The GANG modes are very clear and they are written in the Manual. Like me, if you want to use the usual behaviour you use "GANG None" which is the deafult.
I agree with Igor in that I certainly will get even more confused. Gang methods need to be checked out more by users who are expert on usage from the DAW world. I do not think we should add more options or flexibility until better definitions are presented.
PhyllisSmith wrote:
I have checked into GIT for the manual, the suggestion under NOTES + some clarification as:
When adding a Plugin/Effect in Gang Channels or Gang Media mode to thetrack, highlighted selected region, or In/Out pointers area via dragging theplugin from the Resources Window the plugin will be added on the masterand all slave tracks. If using the Audio or Video pulldown, Attach Effectoption and you want to propagate the effect to all slave tracks, make sure thatthe checkbox for "Attach single standalone and share others" in the Dialogwindow is checked. However, currently when using the right mouse button(RMB) on the master track to Attach effect, the effect will only be insertedon that track.
Very well done, Phyllis! Thanks!
Andrea, so far I agree with your statement -- it seems the most consistent and this fixes 90% of the bug introduced in June, 2020. The other 10% as stated previously is that "drag effect" works for both of 2 Audio channel tracks when in Gang Channels mode BUT "attach effect" does not. Thanks for testing too as I do not always know what is supposed to work and how. I think the best course of action, in line with BT#577, is to use
patches 1 and 2, which work fine, and not use 3 and 0004. I remember it being a long discussion to get that result and I wouldn't want to start all over again. Phyllis, what do you think?
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
Igor BEGHETTO -
Phyllis Smith