Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Pre-Release Discussion

Reply
 
Thread Tools Display Modes
Old 12-08-2022, 09:41 AM   #1
Triode
Human being with feelings
 
Triode's Avatar
 
Join Date: Jan 2012
Posts: 1,180
Default v6.72rc3 - December 8 2022

v6.72rc3 - December 8 2022
  • * Includes feature branch: razor edits on master track envelopes
  • * Includes feature branch: track grouping manager dialog
  • * Includes feature branch: track media/razor edit grouping
  • + ReaScript: improve JSFX name matching in TrackFX_AddByName() [p=2621360]
  • + Track edit grouping: actions that split selected media items respect track edit grouping regardless of media item length/overlap
  • + Track edit grouping: apply grouping when previewing razor edits
  • # Grouping: use Track Grouping Matrix instead of Grouping Matrix in menus and dropdowns
This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode
__________________
Mixing / Brush and Beater Drums Online: www.outoftheboxsounds.com
Triode is online now   Reply With Quote
Old 12-08-2022, 09:46 AM   #2
vitalker
Human being with feelings
 
vitalker's Avatar
 
Join Date: Dec 2012
Posts: 13,333
Default

Quote:
Originally Posted by Triode View Post
[*]+ Track edit grouping: apply grouping when previewing razor edits
Brilliant! Thank you! Triode, can you confirm it is working as expected? I'd say yes.
vitalker is online now   Reply With Quote
Old 12-08-2022, 09:47 AM   #3
Triode
Human being with feelings
 
Triode's Avatar
 
Join Date: Jan 2012
Posts: 1,180
Default

+ Track edit grouping: apply grouping when previewing razor edits

Thanks for letting us try this. I'll definitely give it a spin and feed back here
__________________
Mixing / Brush and Beater Drums Online: www.outoftheboxsounds.com
Triode is online now   Reply With Quote
Old 12-08-2022, 10:34 AM   #4
YuriOl
Human being with feelings
 
Join Date: Sep 2018
Location: lugansk
Posts: 153
Default

Quote:
+ ReaScript: improve JSFX name matching in TrackFX_AddByName() [p=2621360]
Excellent! Thank you!

Last edited by YuriOl; 12-08-2022 at 10:47 AM.
YuriOl is offline   Reply With Quote
Old 12-08-2022, 10:46 AM   #5
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by Triode View Post
+ Track edit grouping: apply grouping when previewing razor edits
This is really great. Thank you so much for this. Is there any chance of using the same logic for marquee select? Again, if it only applies to the initial group at the point of selection, I think that would still be an improvement so that mouse down selection state better reflects mouse up selection.

I think not to put too fine of a point on it, Schwa's example GIF (https://forum.cockos.com/showpost.ph...1&postcount=30) isn't a great real world editing example. It's much more rare one would be editing material across multiple groups at the same time. The only time I ever do that is when I'm using an ALL group - so the workflow being make edits on the current group, enable group all tracks for media/razor edit and make edits, disable ALL and then go back to editing single group.

The majority of group editing is going to be done similar to Triode's GIF (https://forum.cockos.com/showpost.ph...6&postcount=11)

I think when trying to wrangle what to display for group selection on mouse down, leaving it out entirely in order to better accommodate multi-group editing/selection isn't ideal as one use case far outweighs the other. Obviously, this becomes more complex as Reaper allows you to set tracks to lead, follow or both on an individual per-track basis (which is awesome) as well as put the same track in multiple groups but I don't think this should necessitate throwing out the baby (main use cases) with the bathwater (edge cases).

So thanks for listening and trying to find a way to navigate this. IMHO, this implementation in RC3 is already MUCH better!
Klangfarben is offline   Reply With Quote
Old 12-08-2022, 10:49 AM   #6
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,747
Default

Quote:
Originally Posted by Klangfarben View Post
This is really great. Thank you so much for this. Is there any chance of using the same logic for marquee select?
That would be a change in behavior, not just display. The same marquee selection on different grouped tracks results in a different set of selected items:

schwa is offline   Reply With Quote
Old 12-08-2022, 11:28 AM   #7
vitalker
Human being with feelings
 
vitalker's Avatar
 
Join Date: Dec 2012
Posts: 13,333
Default

Quote:
Originally Posted by Klangfarben View Post
Is there any chance of using the same logic for marquee select? Again, if it only applies to the initial group at the point of selection, I think that would still be an improvement so that mouse down selection state better reflects mouse up selection.
The problem with marquee selection is that it is not snapping to track heights and grid as razor edits do.
vitalker is online now   Reply With Quote
Old 12-08-2022, 11:48 AM   #8
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by schwa View Post
That would be a change in behavior, not just display. The same marquee selection on different grouped tracks results in a different set of selected items:

Thank you for pointing that out. So the issue/difference being on marquee mouse down, Reaper can't know what item(s) will ultimately be selected until they are actually selected (which then determines the selection of the other group track items) whereas razor edit is selecting an area so Reaper doesn't have to know. So you either have mouse down possibly not reflecting mouse up (if changed) or mouse up not reflecting mouse down (current behavior).

My only question would be, is changing the mouse down behavior using the same logic as razor edits in RC3 more beneficial than leaving the current implementation as is? Looking at it, it seems that the only scenario where this fails (mouse down does not match mouse up) is when selecting a fully enclosed item shorter than the other items on a leader track or an item that is outside the bounds of the other track items. Whereas, in the current implementation with the selection originating on a leader track, mouse down selection will always not match mouse up selection. Which means that changing the behavior would actually be more accurate than not changing - marquee mouse down not reflecting mouse up on edge cases only vs marquee mouse down not reflecting mouse up on all cases. Since again the most common use case is that grouped track items will be the same length.

In terms of existing behavior, this wouldn't change anything for non-grouped marquee selection. And since track grouping isn't yet officially released, existing behavior for grouped marquee selection doesn't really apply.
Klangfarben is offline   Reply With Quote
Old 12-08-2022, 12:12 PM   #9
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by vitalker View Post
The problem with marquee selection is that it is not snapping to track heights and grid as razor edits do.
Again, it would be based off the origination of the mouse down so whether it snaps to track height is immaterial. It is simply based on where the mouse is clicked on start of marquee select. If it happens anywhere on a leader track, it would use grouped marquee selection as razor edits are now doing. If you take RC3 for a spin, you'll notice that if you razor edit starting in a follow track, it is only selecting the items in that one track. If the razor edit starts on a leader track then it is showing the track grouping on mouse down.

I'm suggesting that doing that with marquee selection would still be better as most of the time mouse down selection on a leader track will then equal mouse up selection (with the exclusion of the example Schwa gives as well as items outside the bounds of other track items), whereas in the current implementation marquee selection on a leader track will most of the time not equal mouse up selection. Since this is the case, I'm making the argument that it would be more beneficial to prioritize the main use case and have mouse down selection match mouse up selection most of the time vs prioritizing the edge cases and having mouse down selection not equal mouse up selection most of the time. If it's going to be wrong, I'd rather have it be wrong less vs what it is doing now.

And keep in mind, razor edits can be set to ignore snap just as marquee select can be set to snap.

Last edited by Klangfarben; 12-08-2022 at 12:37 PM.
Klangfarben is offline   Reply With Quote
Old 12-08-2022, 01:02 PM   #10
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,747
Default

There would also be the issue that previewing the grouped marquee selection would create the impression that envelope points and track envelopes displayed in the media lane of grouped tracks should be selected, but they wouldn't be. So it would not be wysiwyg anyway.
schwa is offline   Reply With Quote
Old 12-08-2022, 01:07 PM   #11
vitalker
Human being with feelings
 
vitalker's Avatar
 
Join Date: Dec 2012
Posts: 13,333
Default

Quote:
Originally Posted by schwa View Post
There would also be the issue that previewing the grouped marquee selection would create the impression that envelope points and track envelopes displayed in the media lane of grouped tracks should be selected, but they wouldn't be. So it would not be wysiwyg anyway.
That's because razor edits can be non-contiguous and marquee selection can't be, right? So if you have, let's say, 9 tracks and first and 9th are grouped, so marquee will select everything in-between, too, which won't happen in case of razor edits.
vitalker is online now   Reply With Quote
Old 12-08-2022, 01:29 PM   #12
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

This is always difficult to visualize so here are a few GIFS that might help clarify my point.

Schwa rightly points out that modifying marquee group select on mouse down to match razor edit mouse down is not ideal in edge cases. Here are the two edge cases I see that would be problematic.

In the first GIF, the user marquee selects in a leader track in Group 1. On mouse down it is selecting the group. But then the user selects just one item outside the bounds of the other items, so on mouse up only that one item is selected (please keep in mind, I'm using razor select here in lieu of marquee edit as marquee selection doesn't currently have the functionality to display these edge cases).



Same thing in the second GIF (which is essentially the GIF Schwa illustrated). The user again marquee selects on a leader track. On mouse down, it is selecting the group but the user ends up selecting an enclosed item so on mouse up, just that item is selected.



These are the two edge cases that fail. However, it should be pointed out that this is not a normal item configuration in track group editing. In most cases, the items will look like Group 2 does in the below GIF. This GIF shows the current implementation where if you marquee select on a leader track, mouse down will not match mouse up selection.



To me, the first two GIFS showing a grouped selection on mouse down and a different selection on mouse up is less problematic than the third GIF which shows no grouped selection on mouse down and grouped selection on mouse up. Especially since the first two GIFS "fail" in just those two edge cases. The third GIF "fails" in the most common use case. So the question becomes do we want this to fail for the most common use case and if not, then are we ok with the edge cases failing in the first two GIFs. IMHO, the third GIF showing the current implementation is more blind than the first two GIFS that show what it would look like if marquee group select was changed to match razor edit group select.
Klangfarben is offline   Reply With Quote
Old 12-08-2022, 01:38 PM   #13
vitalker
Human being with feelings
 
vitalker's Avatar
 
Join Date: Dec 2012
Posts: 13,333
Default

@Klangfarben, was the last comment for me or schwa? Are you saying RC3 has bad behavior now, so the devs should revert changes as they were in RC2? Or you want just similar implementation for marquee selection?
vitalker is online now   Reply With Quote
Old 12-08-2022, 01:46 PM   #14
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by vitalker View Post
@Klangfarben, was the last comment for me or schwa? Are you saying RC3 has bad behavior now, so the devs should revert changes as they were in RC2? Or you want just similar implementation for marquee selection?
I'm arguing that marquee group selection would be better served matching the razor edit group selection of RC3. The above GIFS show what would happen regarding edge cases if it was changed (first two GIFS) vs the current implementation (third GIF). The downside of the third GIF outweighs the downside of the first two IMHO, especially since they are edge cases whereas the third one is definitely not.
Klangfarben is offline   Reply With Quote
Old 12-08-2022, 01:50 PM   #15
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,747
Default

In the interest of preventing this thread from getting too far down a speculative road, after doing some testing here, I think grouping item selection marquee preview won't work. Too many corner cases. The razor edit grouped preview is good though.

Last edited by schwa; 12-08-2022 at 02:19 PM.
schwa is offline   Reply With Quote
Old 12-08-2022, 02:09 PM   #16
Triode
Human being with feelings
 
Triode's Avatar
 
Join Date: Jan 2012
Posts: 1,180
Default

There's also the option of letting marquee selection completely bypass track grouping.
We will have razor edits that obey track groups which is a game changer along with click item selection (of equal length item areas) for track groups.
Is marquee item selection more valuable if it bypasses track grouping?
__________________
Mixing / Brush and Beater Drums Online: www.outoftheboxsounds.com
Triode is online now   Reply With Quote
Old 12-08-2022, 02:34 PM   #17
AZpercussion
Human being with feelings
 
Join Date: Oct 2019
Location: Moscow / Tbilisi
Posts: 909
Default

+ Track edit grouping: actions that split selected media items respect track edit grouping regardless of media item length/overlap

Thanks for that, it seems better anyway. Though item selection choosing is a hard kvest, but such splitting feels right.

Else:
Here several points I mentioned. Hope this gif shows it clear.




1. If only one track selected there is no reasons to prevent changing track selection by clicking on or editing items.

2. This weird prevention works even auto-grouping is off.

3. The line "Enable track grouping" switches both grouping for arrange edits and for TCP controls. We have separate option for item grouping, but not for TCP controls.
I think there could be situation when user need to switch TCP grouping off but preserve grouping for editing.

4. Also it would be nice to have in that dropdown menu a line for opening Track Group Manager, not only matrix.
AZpercussion is offline   Reply With Quote
Old 12-08-2022, 02:46 PM   #18
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by schwa View Post
In the interest of preventing this thread from getting too far down a speculative road, after doing some testing here, I think grouping item selection marquee preview won't work. Too many corner cases.
Thanks for considering it. To be fair, this is being introduced in an RC, so there really isn't another thread to comment. Maybe it could be looked at in the next dev cycle so the discussion wouldn't clog the release getting out? I understand the corner case issues, but I also don't want to throw something out entirely when possible alternatives haven't really been looked at or discussed.

Quote:
Originally Posted by Triode View Post
Is marquee item selection more valuable if it bypasses track grouping?
I'm not sure really. If it does bypass track grouping entirely the one large disadvantage you would have is it would take much longer to make a larger selection. Whereas if it does conform to grouping you aren't having to do so much mousing to select the items you want.
Klangfarben is offline   Reply With Quote
Old 12-08-2022, 03:46 PM   #19
Triode
Human being with feelings
 
Triode's Avatar
 
Join Date: Jan 2012
Posts: 1,180
Default

Quote:
Originally Posted by Klangfarben View Post
If it does bypass track grouping entirely the one large disadvantage you would have is it would take much longer to make a larger selection. Whereas if it does conform to grouping you aren't having to do so much mousing to select the items you want.
Isn't there an action that selects items from a razor edit? That would do the trick. (I can't find it in actions though...where did it go?)

The other side of the coin is that marquee selection could be a quick way of selecting clusters of items without having to disable grouping. It might be worth at least having an option in mouse modifiers to marquee select items and ignore track grouping (or a tick-box that affects the toggle selection and add to selection counterparts also)
__________________
Mixing / Brush and Beater Drums Online: www.outoftheboxsounds.com
Triode is online now   Reply With Quote
Old 12-08-2022, 04:13 PM   #20
Triode
Human being with feelings
 
Triode's Avatar
 
Join Date: Jan 2012
Posts: 1,180
Default Toggle Item Selection Mouse Modifier with track grouping turned on

Is the mouse modifier for "Toggle item selection" not working when tracks are grouped?

Here I'm first selecting a line of items when track grouping is turned off and then toggling them off via that mouse mod. Then I enable track grouping and try the same thing. This modifier seems to only select items in a group but not de-select them.

Edit: This only affects item (top half) select on my system because I have the upper half command drag modifier set to "Select time ignoring snap" which seems to be blocking the item click for track grouping
(The bottom half left drag modifier is set to an item-related one "move item ignoring snap")
If I set the top modifier to an item-related action then grouped toggle clicks work with this modifier.

NB when I made my track grouping action scripts I remember I had to get around this same problem by changing how the item under the mouse was selected in the script.

__________________
Mixing / Brush and Beater Drums Online: www.outoftheboxsounds.com

Last edited by Triode; 12-08-2022 at 05:35 PM.
Triode is online now   Reply With Quote
Old 12-08-2022, 05:00 PM   #21
Triode
Human being with feelings
 
Triode's Avatar
 
Join Date: Jan 2012
Posts: 1,180
Default Drawing/Extending RE area when grouped in this RC

Please let this not be a bug that causes the removal of grouped razor edit preview (generally it feels good to use).

The RE dissapearance happens also when dragging the lower initial selection down to extend into the envelope area.
Note the second time I draw the initial razor edit and finish it off as if the tracks weren't grouped it doesn't happen

This whole scenario doesn't occur in 6.72rc2 (boo)

__________________
Mixing / Brush and Beater Drums Online: www.outoftheboxsounds.com
Triode is online now   Reply With Quote
Old 12-08-2022, 05:55 PM   #22
AZpercussion
Human being with feelings
 
Join Date: Oct 2019
Location: Moscow / Tbilisi
Posts: 909
Default Marquee toggle item selection

Quote:
Originally Posted by Triode View Post
Is the mouse modifier for "Toggle item selection" not working when tracks are grouped?
The same via right drug. It's ok that this action respect grouping, but it's called "toggle". I can select now, but not deselect items. And when autogrouping is off I can both.
AZpercussion is offline   Reply With Quote
Old 12-08-2022, 06:01 PM   #23
Triode
Human being with feelings
 
Triode's Avatar
 
Join Date: Jan 2012
Posts: 1,180
Default

Quote:
Originally Posted by AZpercussion View Post
The same via right drug. It's ok that this action respect grouping, but it's called "toggle". I can select now, but not deselect items. And when autogrouping is off I can both.
AZ, do you also have a non-item-related left-drag action mapped to the same modifier key as your "toggle item selection"? Try changing that to an item-related one and see if toggle select starts working in the track group
__________________
Mixing / Brush and Beater Drums Online: www.outoftheboxsounds.com
Triode is online now   Reply With Quote
Old 12-08-2022, 06:05 PM   #24
AZpercussion
Human being with feelings
 
Join Date: Oct 2019
Location: Moscow / Tbilisi
Posts: 909
Default Bug behavior with locked items



It might be that way the locked item can be edited if the user edit it directly. Kind of smart behavior.
But it works the opposite.

And yeah, this smart behavior doesn't exist in Reaper yet, so it would be inconsistent. Maybe in future...
AZpercussion is offline   Reply With Quote
Old 12-08-2022, 06:16 PM   #25
AZpercussion
Human being with feelings
 
Join Date: Oct 2019
Location: Moscow / Tbilisi
Posts: 909
Default

Quote:
Originally Posted by Triode View Post
AZ, do you also have a non-item-related left-drag action mapped to the same modifier key as your "toggle item selection"? Try changing that to an item-related one and see if toggle select starts working in the track group
Do you mean the left drag and the right drag have relationships?
I have "Move item ignoring snap and time selection" at left drag+shift and "Toggle item selection" at the right+shift.
It seems they don't influence each other.
Anyway, toggle should work in both directions.
AZpercussion is offline   Reply With Quote
Old 12-08-2022, 06:29 PM   #26
Triode
Human being with feelings
 
Triode's Avatar
 
Join Date: Jan 2012
Posts: 1,180
Default

Quote:
Originally Posted by AZpercussion View Post
Do you mean the left drag and the right drag have relationships?
I have "Move item ignoring snap and time selection" at left drag+shift and "Toggle item selection" at the right+shift.
It seems they don't influence each other.
Anyway, toggle should work in both directions.
I mean that left drag has a blocking relationship with left CLICK in grouped tracks if left drag is mapped to a non-item-related action
__________________
Mixing / Brush and Beater Drums Online: www.outoftheboxsounds.com
Triode is online now   Reply With Quote
Old 12-09-2022, 02:59 AM   #27
mlprod
Human being with feelings
 
Join Date: Jul 2015
Location: Stockholm, Sweden
Posts: 1,343
Default

Please don't change how marquee selection works.
__________________
Magnus Lindberg Productions - VRTKL Audio - Redmount Studios
magnuslindberg.com
mlprod is offline   Reply With Quote
Old 12-09-2022, 03:28 AM   #28
AZpercussion
Human being with feelings
 
Join Date: Oct 2019
Location: Moscow / Tbilisi
Posts: 909
Default

Quote:
Originally Posted by mlprod View Post
Please don't change how marquee selection works.
Here is no talks about changing how it works in currently possible cases.
The question is how it should work in new cases which we get from new feature.
AZpercussion is offline   Reply With Quote
Old 12-09-2022, 04:48 AM   #29
AZpercussion
Human being with feelings
 
Join Date: Oct 2019
Location: Moscow / Tbilisi
Posts: 909
Default

I've looked at marquee selection as a solution for tails problem.

Could we have this suggested marquee selection (behaving like razor in current rc) optionally?

So, if some items aren't in group because of unique fades/crossfades and we cant't choose them all by clicking at one of them, we can use marquee selection catching all items in follower tracks automatically.

We should be careful at edges where we can grab neigbour items, but as option it would be useful.
It really can close most of cases. Because if we use autogrouping the items will not have too mich differencies in their lenght, just some optimizations.
AZpercussion is offline   Reply With Quote
Old 12-09-2022, 07:22 AM   #30
amagalma
Human being with feelings
 
amagalma's Avatar
 
Join Date: Apr 2011
Posts: 3,451
Default

Quote:
Originally Posted by mlprod View Post
Please don't change how marquee selection works.
I agree! The new RE selection visuals are super though!
__________________
Most of my scripts can be found in ReaPack.
If you find them useful, a donation would be greatly appreciated! Thank you! :)
amagalma is offline   Reply With Quote
Old 12-12-2022, 02:40 AM   #31
soulaccess
Human being with feelings
 
soulaccess's Avatar
 
Join Date: Jul 2012
Posts: 43
Default

I think a new problem with TrackFX_AddByName() was introduced in 6.70 when this problem here got fixed:
Quote:
Originally Posted by sockmonkey72 View Post
v6.70rc1 - November 14 2022
  • + ReaScript: improve behavior with Track/TakeFX_AddByName() for JSFX [t=271878]
unfortunately this recent fix does not help:

Quote:
Originally Posted by Triode View Post
v6.72rc3 - December 8 2022
  • + ReaScript: improve JSFX name matching in TrackFX_AddByName() [p=2621360]
the problem is: when you pass the name of an FX (as defined by the desc: tag) to TrackFX_AddByName(), it often fails (just an blank fx appears) - this used to work just fine pre 6.70
when passing a filename of an FX to the function it works as expected.
seems to happen on Mac & Win, but not on Linux(?)

Last edited by soulaccess; 12-12-2022 at 02:54 AM.
soulaccess is offline   Reply With Quote
Old 12-12-2022, 07:34 AM   #32
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by soulaccess View Post
I think a new problem with TrackFX_AddByName() was introduced in 6.70 when this problem here got fixed:

unfortunately this recent fix does not help:



the problem is: when you pass the name of an FX (as defined by the desc: tag) to TrackFX_AddByName(), it often fails (just an blank fx appears) - this used to work just fine pre 6.70
when passing a filename of an FX to the function it works as expected.
seems to happen on Mac & Win, but not on Linux(?)
Ahh, it depends on the JSFX display options in the FX browser, it seems. Fixing.

Btw, in 6.69 and earlier passing a name didn't work _at all_. Can you confirm that?

Last edited by Justin; 12-12-2022 at 07:43 AM.
Justin is offline   Reply With Quote
Old 12-12-2022, 08:23 AM   #33
soulaccess
Human being with feelings
 
soulaccess's Avatar
 
Join Date: Jul 2012
Posts: 43
Default

Quote:
Originally Posted by Justin View Post
Ahh, it depends on the JSFX display options in the FX browser, it seems. Fixing.

Btw, in 6.69 and earlier passing a name didn't work _at all_. Can you confirm that?
No, to the contrary, passing a name used to work fine in 6.69 and earlier.
Thanks for looking into it!
soulaccess is offline   Reply With Quote
Old 12-12-2022, 08:39 AM   #34
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by soulaccess View Post
No, to the contrary, passing a name used to work fine in 6.69 and earlier.
Thanks for looking into it!
Are you sure, have you checked? Looking at the code it shouldn't have (unless the name happened to be the same as the filename!)
Justin is offline   Reply With Quote
Old 12-12-2022, 09:05 AM   #35
soulaccess
Human being with feelings
 
soulaccess's Avatar
 
Join Date: Jul 2012
Posts: 43
Default

Quote:
Originally Posted by Justin View Post
Are you sure, have you checked? Looking at the code it shouldn't have (unless the name happened to be the same as the filename!)
Yes and yes. I just double checked, installed V6.69 and FX names work perfectly fine - also tested with names that are completely different from the file name. It just works somehow. This is on macOS Mojave, btw
soulaccess is offline   Reply With Quote
Old 12-12-2022, 10:50 AM   #36
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by soulaccess View Post
Yes and yes. I just double checked, installed V6.69 and FX names work perfectly fine - also tested with names that are completely different from the file name. It just works somehow. This is on macOS Mojave, btw
Make me a screen recording, I think it might be user error :/
Justin is offline   Reply With Quote
Old 12-12-2022, 12:09 PM   #37
soulaccess
Human being with feelings
 
soulaccess's Avatar
 
Join Date: Jul 2012
Posts: 43
Default

here you go, sorry for the low quality, not sure how others upload screen caps in pristine quality.
first I show the script, which is simply:
Code:
track = reaper.GetSelectedTrack2(0, 0, true)
reaper.TrackFX_AddByName(track,'test for justin',false,1)
then I execute it, FX opens. I click on edit and the code starts with:
Code:
desc:test for justin
the FX file is here
Code:
REAPER⁩/Effects/BNC⁩/TestPlugin.jsfx
Reaper V6.69
hope this helps
Attached Images
File Type: gif Untitled-2.gif (235.5 KB, 81 views)
soulaccess is offline   Reply With Quote
Old 12-12-2022, 12:19 PM   #38
vitalker
Human being with feelings
 
vitalker's Avatar
 
Join Date: Dec 2012
Posts: 13,333
Default

Quote:
Originally Posted by soulaccess View Post
here you go, sorry for the low quality, not sure how others upload screen caps in pristine quality.
We use external services like https://stash.reaper.fm/ https://imgur.com/ etc.
For GIF recording we use:
http://cockos.com/licecap/

I usually set it to 5-6 FPS.
vitalker is online now   Reply With Quote
Old 12-12-2022, 12:22 PM   #39
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by soulaccess View Post
here you go, sorry for the low quality, not sure how others upload screen caps in pristine quality.
first I show the script, which is simply:
Code:
track = reaper.GetSelectedTrack2(0, 0, true)
reaper.TrackFX_AddByName(track,'test for justin',false,1)
then I execute it, FX opens. I click on edit and the code starts with:
Code:
desc:test for justin
the FX file is here
Code:
REAPER⁩/Effects/BNC⁩/TestPlugin.jsfx
Reaper V6.69
hope this helps
It's very clearly opening the wrong plug-in (what's all that UI? the TestPlugin.jsfx was an empty jsfx!)...
Justin is offline   Reply With Quote
Old 12-12-2022, 01:39 PM   #40
soulaccess
Human being with feelings
 
soulaccess's Avatar
 
Join Date: Jul 2012
Posts: 43
Default

Quote:
Originally Posted by Justin View Post
It's very clearly opening the wrong plug-in (what's all that UI? the TestPlugin.jsfx was an empty jsfx!)...
hmm, no, it's the correct plugin, I just made the window small for the screen cap so the rest of the code is hidden. it's an FX I have written (that's all the UI).
It's ok, I just wanted to help, I'll use the file name in the future. no worries.
soulaccess is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 05:16 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.