gmem_attach(nil) should return the currently attached gmem(Done)

[Meo-Ada Mespotine]

I'm currently preparing a new feature for Ultraschall-API, where I want to add a JSFX into the monitoring-fx-chain to measure input-signals which sends this information via gmem.

Now I would like to have Lua-functions, who read these values out to give feedback on volume, frequencies, etc.

Problem is: when I attach my own gmem-space.
When the user has attached their own gmem and run my function, I attach my own gmem to read out the values.
Now I would like to revert back to the gmem of the user to "clean up behind me".

But I can't as I have no way to find out, which gmem was attached before I attached my one.

So I would like to have reaper.gmem_attach(nil) to return the currently attached gmem-name, so I can revert back to it for the convenience of the user of my functions after having done my stuff.

[mschnell]

How exactly do you attach "your" gmem in the JSFX ?

Same should be bound to a propriety name of yours (e.g. via "_global.someUniquelyNamedVariable" or "options:gmem=someUniquelyNamedSpace" ) and hence not prone to interference with other "user" 's stuff.

How do you attach to that particular memory in your script (maybe you can translate such line to EEL to have me understand it.)

I found that in EEL Reascripts, "_global.someUniquelyNamedVariable" does not seem to work to attach to the global JSFX Namespaces.

I found that in EEL Reascripts, the corresponding notation for "options:gmem=someUniquelyNamedSpace" is "//@gmem=someUniquelyNamedSpace".

-Michael (no idea at all about LUA)

[Meo-Ada Mespotine]

It doesn't matter how it's done in JSFX or VideoProcessor.
For instance, someone wants to attach the video peek-JSFX in a Luascript, which is part of Reaper.
Now, if I attach my own gmem and no matter what it's named like, I cannot reset it to video peek-gmem in Lua, as I don't have the old gmem-name.

So the user's attachment is lost or better, is now using my gmem, as I can't unattach it either.

I don't know how Eel does it but as far as I know, Eel can some things better than Lua can and I suppose, if you can get the current gmem-name in Eel, it's one of those things missing in Lua and existing in Eel.

So I can't translate it. In Lua there's only attach, read and write.

I could try hijacking the gmemattach-function, but this would be ugly to replace Reaper's Api-functions with an equivalent that stores in a backgroundvariable the used gmem name.

It's a pure Lua problem, afaik.

[lb0]

I'm a little confused by this. When you attach to a gmem space from a script - doesn't it affect that script only (even if the gmem space is used by another running script)? This is the way I've been working - and use several deferred scripts at once - each using its own gmem space or a shared space with another script - and not once have I had any issues. I'm not reattaching each defer cycle - I do occasionally switch gmem spaces when required - but still - each script always seems to be happily connected to the correct gmem space.

Therefore - it's very easy to keep track of what my scripts are attached to - and I never worry about what any other scripts may be attached to. I never need to switch back to another gmem space because another script is using it.

Of course - you may be doing something different to me - but I can't work out the need for your query. Saying that - I don't know how it treats a 'required' library script - whether changing the gmem space in the library function will affect the calling script or not - but it would be easy to test if this is the case.

If this is a problem (I don't know - I've never tried it) - could you have an additional gmem identifier parameter to any of your functions that change the connected gmem? - so you can switch back to this within your function if it is provided? Then it's down to the user to pass in any gmem space they might be connected to. Another alternative is that the user could be aware that using your function will change the attached gmem space - and automatically reattach to the appropriate gmem after calling your function.

[Meo-Ada Mespotine]

Ok, I think I need to clarify this even further:

Assume the following script:

-- this sets the gmem attached in this script to "ThisIsMyGMEM"
reaper.gmem_attach("ThisIsMyGMEM")

-- the following function sets the currently attached gmem to "jsfx_to_video"
Retvals=ultraschall.GetVideoPeekInformation()


-- now the scripter wants to read the gmem and assumes, it is from "ThisIsMyGMEM"
-- where ultraschall.GetVideoPeekInformation set it to "jsfx_to_video"
reaper.gmem_read(1)

-- So the user is now reading from the wrong gmem, as I had no
-- chance in ultraschall.GetVideoPeekInformation to reset 
-- it back to "ThisIsMyGMEM" as there's no way to
-- store the old gmem-name in the backgronud, before I changed it

Additional parameters would be possible but are bad as well. If I add functions for the user and need to change stuff in the back, I always should restore the former states back without having to bother the user at all.
It would otherwise also mean burdening the management of what the current gmem-name is to the scripter, and if they are using different ones in a script, changing back and forth, it can become confusing, as they always would need to do stuff like:

CurrentAttach="name"
reaper.gmem_attach(CurrentAttach)

retval = ultraschall.GetVideoPeekInformation(CurrentAttach)

my_value=reaper.gmem_read(1)

CurrentAttach="Another name"
reaper.gmem_attach(CurrentAttach)

my_value=reaper.gmem_read(123)
ultraschall.GetVideoPeekInformation(CurrentAttach)

This simply clutters code, even in this simple example, let alone more complex scripts. And cluttering is always a great source for bugs.
I would prefer it more like that:

reaper.gmem_attach("name")
retval = ultraschall.GetVideoPeekInformation()
my_value=reaper.gmem_read(1)

reaper.gmem_attach("Another name")
my_value=reaper.gmem_read(123)
ultraschall.GetVideoPeekInformation()

Much cleaner.
Good API-functions should not build up clutter and barricades. They should step aside and help you make things easier, not harder and possibly confusing.

And as I intend to do a lot with the video-processor in the future as well(using tons of gmems), having to deal with that could become a pure coding-clusterfuck, if users would work with their own gmems in these Lua-Scripts alongside my video-processor-functions.
I prefer to make this stuff as clean and simple as possible and clean up after myself.

And all I need to make this properly is a way of getting the current attached gmem in the current Lua-script, which should be known by Reaper anyway.

[mschnell]

Originally Posted by Meo-Ada Mespotine

if you can get the current gmem-name in Eel,

You can't "get" an gmem-name, you only can decide to attach to a named gmem-instance (only to one, and you can't dynamically change to another one).

So gmem names only prevent incidentally overlapping gmems for groups of plugins/scripts that don't know each other.
Handling multiple instances of JSFXes needs manually programming in their common gmem: counting instances in a common spot (e.g. gmem[0] as a number or a bit field), each plugin / instance holding its number in a local variable (use a slider to show the instance number for debugging) and assigning gmem regions (ranges of array indices) to each. I in fact once did this successfully.

-Michael

[mschnell]

@meo: did you get this decently working ?

-Michael

[Meo-Ada Mespotine]

Nope. Unless I hijack gmem_attach to replace it with my own function that stores the chosen gmemname in a variable in the back(possible in Lua), I cannot do anything about it.

[Justin]

Making it return the old value for all calls. Not going to make it accept nil though, yet...