v4: SWS/S&M Extension

[sws]

Originally Posted by nightscope

]
Is there any way to stop the Rconsole from closing everytime you use it? I want it to remain open and on top until I dismiss it.

Use ctrl+enter to run the command.

[nightscope]

Originally Posted by sws

Use ctrl+enter to run the command.

Fab.

Cheers,

ns

[gwok]

hey, I just had a thought and figured I'd bring it up here for discussion before making an FR at SWS.

Would it be possible to store any pertinent snapshot information for a track within a track template?

What I'm thinking is say I have a track with some effects, and I have a few different snapshots for the FX Chain setting on that track, then if I stored that track as a TrackTemplate, the snapshot information would be part of it. Then when loading that track template, the snapshot(s) would get imported to the shapshot list.

Any thoughts? Is that something that would be realistic\worthwhile to implement, or even possible?

cheers

[sws]

Originally Posted by Jeffos

these first reascrpit goodies will be in the NEXT release ...

2.3.0 #5 is available at the beta site.

Please let us know if you have issues with the new ReaScript functions or the new OSX installer.

[Viente]

Going to check it now! Thanks!

[gofer]

I'm making a note here: Huge success!



Tested so far:
SNM_GetMediaItemTakeByGUID
SNM_GetSetSourceState (YAY!!!!)
SNM_AddReceive
SNM_GetIntConfigVar
SNM_SetIntConfigVar (only tested ConfigVar with "miditicksperbeat", is there a list of varNames somewhere?)

with not a single problem whatsoever on winXP SP3 (32bit)

[Viente]

yeah all smooth so far! cheers!

[drew]

Originally Posted by gofer

SNM_SetIntConfigVar (only tested ConfigVar with "miditicksperbeat", is there a list of varNames somewhere?)

I've not been able to get hold of such a list

You might think it would all tally with the INI var names, but the mystery for me is it doesn't - miditicksperbeat means something totally different.

In the INI it's 960 by default, in the program it's 4

[gofer]

Aside (not an extension issue, but I need to get it off my chest):
I'm a bit sad that I still can't seem to get some edits in the CFGEDIT line (of a MIDI take) to stick. The note length value lives in there for example and I can't get it to change - I'd love to reset it to "grid" via action (end goal is to set it to "grid minus a tiny tad"). It's a thing I noticed before with the stock GetSet state functions, it's not on you to fix.
I had only little hope that the new approach would change the situation, but still, there was a little hope .

[drew]

Originally Posted by Veto

i think it should be the Reaper.ini, i can set "miditicksperbeat" and other stuff to the correct values.
But these are just keys in the REAPER section.

Oh really? I've not been able to try yet, but when you run REAPER and do SNM_GetIntConfigVar for miditicksperbeat, do you not get "4" as the value? Maybe there's some actual magic going on beyond the clever coding I've come to expect

Thanks

[gofer]

Originally Posted by Veto

i think it should be the Reaper.ini, i can set "miditicksperbeat" and other stuff to the correct values.
But these are just keys in the REAPER section.

I'm wondering if we also could access the midiedit section, because "lastdrummode" for example wont work here.

Yep. REAPER section of Reaper.ini it seems to be. Of course first thing I tried was "lastnotelen" in the midiedit section . No worky. But ints and floats in the Reaper section were all working as far as I tried. Wow, that's pretty powerful still.

I guess we should formulate a Reaper bug report about CFGEDIT and CFGEDITVIEW...

[Jeffos]

GREAT!
Did someone tested exported functions on OSX? (timlloyd?)

Originally Posted by gofer

hahaha! good to see this one again!! there was a long time we did not share a e-cigar gofer!
if things go well (as it seems to be the case) I'll export more things to you guys..

about CFGEDIT/CFGEDITVIEW: I think theres a solution.. need to double-check..

Originally Posted by drew

You might think it would all tally with the INI var names, but the mystery for me is it doesn't - miditicksperbeat means something totally different.
In the INI it's 960 by default, in the program it's 4

no drew! with these exported functions you will get the correct value, i.e. 960

in fact, I actually added those ConfigVar because of that prob I did not reply to you here but it was "normal" your python code was failing (in short, you can't use APIs returning void* in ReaScript w/o extra hassle.. oh! and since we're there, for this other unanswered Q, just remove the "blabla/" part!)

[EvilDragon]

Originally Posted by gofer

I'm making a note here: Huge success!

Link

[gofer]

Originally Posted by Jeffos

GREAT!
hahaha! good to see this one again!! there was a long time we did not share a e-cigar gofer!
if things go well (as it seems to be the case) I'll export more things to you guys..

about CFGEDIT/CFGEDITVIEW: I think theres a solution.. need to double-check..

It's well deserved Jeffos. We didn't have so many lately mostly because I
a) got a bit lazy with scripting as a whole
b) got a bit better at it (ever so slightly)
c) got better at guessing whether a script idea will be problematic and either find ways around or just let it be

Be sure, the next one is on the horizon Teaser: Has to do with editing sends from the send track side instead of from the receiving side. iow, finding the relevant auxrecv for given send slot(s) - found a way but it depends on the receiving track names being unique... Fun fact: it is easy, fast and reliable if the receiving track(s) are unnamed. But that's for another time and thread


It is so utterly cool how your take state function makes our weird little "find the relevant take section in the item state chunk" workaround routine obsolete! Main thing with states in ReaScript was of course the maxlen, but you gave it that good portion of extra creme coating. Getting at the take data is easy as pie now. Delicious!
(If I now could get my head around what Veto did to obey midi filter settings and all his extra safety code concerning SysEx and stuff, I'd help him update his reaper_midi.py library. But as much as I bang my head, it's too big for my brain cell )


Dear Santa, if I was granted a wish for the next function exports it would be get/set track states.

[hopi]

trying reapol py... I get this error

my other py scripts all working ok

what am I doing wrong?

[IMG]http://**************/a/img850/9182/goferscriperror.png[/IMG]

[gofer]

Ooops, you're right! I didn't think of that the "active take vs active in ME" thing basically stays the same We still have to do the little pointer compare routine it seems. No biggie, methinks.

[hopi]

Originally Posted by Veto

you need to download the latest sws beta (offering new functions for Reascripters)
The little repool items script only supposed to be a foretaste of what is possible now (i'll better take it off for now, to not confuse anybody).

Sry SWS for the OT.

Thanks Veto... ok, I'll get the beta and see what this shows... just for curiosity sake...

[RJHollins]

Hello Gang,

Hope I can get a little help from the SWS thread, since not having much luck with my searching.

In another thread the discussion regarding 'gain staging' ...

In that thread I was alerted to the SWS function that would scan a track and report back the PEAK/RMS level. This is very handy!

My question is, is there a way to do a 'scan' through the FX bin and display the track output Peak/RMS value ??

This would be an invaluable workflow time saver.

Thanks for any insights.

Sincerely.

[gwok]

can anyone confirm if Snapshots>recall selected tracks only> is working (im)properly. Doesn't seem to be working for me

thanks'

[Viente]

Is it possibe to have GetType() in the next release please?

[Michiel Papenhove]

Just downloaded the latest version of SWS and if I now make a Mixer snapshot (64 bit version of SWS btw) and try to recall that snapshot, it takes at least ten seconds to recall. I myself do not recall that this was the case before... Or am I just really mistaken? Anyone else have the same problem?

regards,
Michiel.

[musicbynumbers]

Could it be certain effects you have loaded? some effects are quite large data wise and if you have the effects box ticked in snapshots that will make snapshots store a lot of data on some effects.

Having said that, I haven't seen this problem for ages but do recall having it along time ago. I'm sure someone will help soon though!

Originally Posted by Michiel Papenhove

Just downloaded the latest version of SWS and if I now make a Mixer snapshot (64 bit version of SWS btw) and try to recall that snapshot, it takes at least ten seconds to recall. I myself do not recall that this was the case before... Or am I just really mistaken? Anyone else have the same problem?

regards,
Michiel.

[Jeffos]

ReaScript: Guys! WAIT!
I see some scripts using beta funcs on the forum! This is cool but in these beta versions please consider some little things *will* change (exported funcs will be engraved on the rock in the next "official" release of the extension). For ex. the SNM_GetSetSourceState() interface wiil change at some point: is reascript-friendly but it does not make sense for other plugins (in C++).

This is a WIP.
The 1st step was to make it dead easy to share some code with you.
The 2nd step now is to define HOW we will export things to you..
..especially, for reascript, how to deal with that painful state chunk length limitation. I'll post 2 propositions soon.

About API requests:
we need to agree on the stuff above before adding any new func (and it might require some time to get feedback from enough/different ReaScripters).
In the meantime I have added an FR in the SWS tracker for API requests: FR 513)

Originally Posted by gofer

It is so utterly cool how your take state function makes our weird little "find the relevant take section in the item state chunk" workaround routine obsolete! Main thing with states in ReaScript was of course the maxlen, but you gave it that good portion of extra creme coating. Getting at the take data is easy as pie now. Delicious!

Thanks gofer! Yes, that's the idea. I've chosen these first "test" funcs because of some ReaScripts probs that are often discussed (or because of buggy regex scripts ) BUT, in this first version, you still have the max. state length limitation!! (i.e. 4Mb like "RPR_" functions) => it's the "2nd" step I was talking about.. will come back to post about that..

Originally Posted by Veto

I see the neccessity of getting the take chunk by index because of otherwise unidentifiable empty takes, but there could be discrepancies between the selected take and the currently active take in the midi-editor.

Hey Veto! Good to see you back
Empty takes, that's it but yeah, it isn't handy with the ME. I'll also add an interface with a MediaItem_take* param (..but later)

Originally Posted by Jeffos

Did someone tested exported functions on OSX?

bump!

[Jeffos]

Originally Posted by Mr. Data

You can download the langpack file here https://stash.reaper.fm/13953/Deutsch...ReaperLangPack.

Thanks for that and thanks again for the very detailed report Mr Data!
I've fixed the localization issues you have raised. Just to let you know that, in the next build, you would also need a new SWS Template LangPack file to have everything fixed (we generate those for new official releases of the extension but I can generate one if you want, let me know!). Now, I'll look at the "missing space" issues..

Originally Posted by Michiel Papenhove

Just downloaded the latest version of SWS and if I now make a Mixer snapshot (64 bit version of SWS btw) and try to recall that snapshot, it takes at least ten seconds to recall. I myself do not recall that this was the case before... Or am I just really mistaken? Anyone else have the same problem?

sorry for the trouble but humm.. no recent updates afaik. please, can you enter an issue in the sws tracker (http://code.google.com/p/sws-extension/issues/list) with your OS specs and attach a RPP file (no media needed, just the RPP) saved just before recalling that "slow" snapshot? that ould help!

[Jeffos]

Originally Posted by Jeffos

The 2nd step now is to define HOW we will export things to you..
..especially, for reascript, how to deal with that painful state chunk length limitation. I'll post 2 propositions soon.

Ok, so here are 2 propositions to deal with string limitation in ReaScript and offer better interfaces for c++ plugins.
=> ReaScripters, please let us know what you think!

.. and any other idea welcome, of course!



1) Best solution (but complicated/confusing?)

You would have to deal with strings in a different/indirect way (so that the extension can fully manage memory allocations).
=> no more limit + tighter mem alloc (i.e. just allocating what is needed rather than blocks of 4Mb (even when only 16Kb is needed))

The related APIs would look like:

// [S&M extension] Instanciates a new "fast string" (i.e. WDL_FastString).
// Once the job done, you MUST delete this string, see SNM_DeleteObject.
WDL_FastString* SNM_CreateFastString(const char* str)
//[S&M extension] Gets the "fast string" content as a "standard string".
const char* SNM_GetFastString(WDL_FastString* str)
// [S&M extension] Deletes an object instance.
void SNM_DeleteObject(void* obj)

// [S&M extension] Gets or sets a take's source state. Use takeIdx=-1 to get/alter the active take.
bool SNM_GetSetSourceState(MediaItem* item, int takeIdx, WDL_FastString* state, bool setnewvalue)

^^
- check out SNM_GetSetSourceState(), in compraison with the current beta the "state" param is not a char* but a WDL_FastString*
- "WDL_FastString !?à#ù£??" => that name is pretty clear and that's the only thing you need to know
- the other funcs just allow you to deal w/ those "fast strings": create, set the string, get it, delete

ReaScript example. Dumping a source state would look like:

fastStr = SNM_CreateFastString("")
ret = SNM_GetSetSourceState(RPR_GetSelectedMediaItem(0, 0), -1, fastStr, False)
f = open('c:\\test.txt', 'w') # test with a file because RPR_ShowConsoleMsg won't support massive data
f.write(SNM_GetFastString(fastStr))
SNM_DeleteObject(fastStr)

^^ this code has been tested with a >16Mb string (cheated w/ a track state, not a source state).

This would be the best solution IMO... this could enable some cool stuff too BUT it is not straight-forward (?)
Note: there's a better way to expose "fast strings" but that would complicate things even more (ctype tricks).



2) "Maxlen" solution (more reascript friendly?)

Like RPR_ funcs, the memory still allocated in a brutal way BUT here you can customize the brutality via a variable, say "SWS_STR_MAXLEN".
When a func uses a "maxlen" param, you would use this SWS_STR_MAXLEN, no matter what (internal value used to allocate ALL strings, i.e. "char*" params - note: "const char*" is something else!).
You could also detect and deal with truncated strings too.

The related APIs would look like:

// [S&M extension] Gets or sets a take's source state.
// Returns <= 0 when the function fails or
// - get: the *real* state length, so if > stateMaxlen => failed
// - set: > 0 if ok
int SNM_GetSetSourceState(MediaItem* item, int takeidx, char* state, int statemaxlen, bool setnewvalue)

^^ There is also a SNM_SetStrMaxlen(n) func that will not be documented (in the html reascript doc) for some reasons.
Basically, it does SWS_STR_MAXLEN=n but this instruction is no-op from your scripts (can't alter an exported global var like that in python, and that's not so bad..).

So, in short, you can read SWS_STR_MAXLEN but, to change it, you have to use SNM_SetStrMaxlen(n)

ReaScript example. Sets a state with a bit better mem alloc and skip possible "overflows":

state = open('c:\\test_in.txt', 'r').read() # say this file contains a 16Mb state
SNM_SetStrMaxlen(len(state))
ret = SNM_GetSetTakeSourceState(0, state, SNM_STR_MAXLEN, True)
if ret[0]>0:
   # do some stuff

ReaScript example. Gets a state and detect an "overflow":

ret = SNM_GetSetTakeSourceState(0, "", SNM_STR_MAXLEN, False)
if ret[0]>0 and ret[0]<=SNM_STR_MAXLEN:     # ok! we got a proper state
   open('c:\\test_out.txt', 'w').write(ret[2])
else:
   # do some stuff -OR- 2nd try with the needed realloc: SNM_SetStrMaxlen(ret[0])

Notes:
- slow/less efficient (but more reascript friendly?)
- it would be important to maintain SWS_STR_MAXLEN as low as possible
- this would apply to SWS funcs only ("RPR_" funcs would still be limited to 4Mb)


2bis) Solution for punks

SNM_SetStrMaxlen(32*1024*1024)

_____________

I have the code for both ideas. I can push this stuff in a beta but the 2 solutions are incompatible..
.. want to try? which one?

[timbralzoom]

Thank you so much Jeffos

remove empty items...now works great!

[Mr. Data]

Originally Posted by Jeffos

Thanks for that and thanks again for the very detailed report Mr Data!
I've fixed the localization issues you have raised. Just to let you know that, in the next build, you would also need a new SWS Template LangPack file to have everything fixed (we generate those for new official releases of the extension but I can generate one if you want, let me know!). Now, I'll look at the "missing space" issues..

Thank you, Jeffos. I really appreciate this.

And yes, it would be nice to have a langpack, so I can get on with translating.

BTW: Is there something special I have to take care of (besides using copies, of course) to not lose the translations I did up to now when joining the files?


-Data

[gofer]

How risky is solution 1? What will happen when the object doesn't get deleted because of my fizzy brain, say when the script fails before it reaches SNM_DeleteObject(fastStr)?

When I then run the script again (or am crazy enough to script a loop creating the same object over and over) will the old object be killed when the script creates it again (with the same variable name)? So that it's not all that bad as long as we don't run many different faulty scripts all creating big objects?

If that's so, I think I prefer 1.

[DBMusic]

SWS:Analyze and display item peak and RMS

Just wanted to say "thank you!" for that one.

DB

[Jeffos]

Localization:

Originally Posted by Mr. Data

And yes, it would be nice to have a langpack, so I can get on with translating.

BTW: Is there something special I have to take care of (besides using copies, of course) to not lose the translations I did up to now when joining the files?

Ok! I'll upload a template LangPack for the next beta then! Especially since EVERYTHING is now localized
For the merge, it is better to have separated SWS.de & REAPER.de langpacks (because one day we might be able use them separately) but in any case, no, nothing special, your translations will be preserved.

___

ReaScript:

Originally Posted by gofer

How risky is solution 1? What will happen when the object doesn't get deleted because of my fizzy brain, say when the script fails before it reaches SNM_DeleteObject(fastStr)?

you will get a memory leak (w/ chunk states, possibly a leak of several Mb), this can steal all the memory and make things crash at some point (e.g. leak in a loop).
however, if the "script fails before it reaches SNM_DeleteObject()" that would mean there is a bigger prob: your script is buggy

Originally Posted by gofer

When I then run the script again (or am crazy enough to script a loop creating the same object over and over) will the old object be killed when the script creates it again (with the same variable name)? So that it's not all that bad as long as we don't run many different faulty scripts all creating big objects?

the "old object" won't be killed, you have of take care of the deletion. however, depending of what you do, you can create a single FastString, use it for different things in a loop and delete it outside the loop but you really have to delete it before the end of the script (and whatever "path" uses the code).

[gofer]

Originally Posted by Jeffos

however, if the "script fails before it reaches SNM_DeleteObject()" that would mean there is a bigger prob: your script is buggy

Yep, buggy script on my end is definitely the scenario I talk about . Most of mine are buggy while I write them. I'm doing quite a bit of trial and error on the way .
But I just learned from Veto about this possibility:

fastStr = SNM_CreateFastString("")

gofers-bug-ridden-test-code
runs-and-fails-somewhere-here

finally:
    SNM_DeleteObject(fastStr)

which should kill the object even if my script failed in the middle part, if I understand the "finally" thingie right. I think I could handle that .

[Viente]

Originally Posted by Veto

o scripters where art thou ??

I'm super interested! However im not sure i can't give any valuable feedback right now becuase it seems i still need to learn more simple things atm. But i would love to provide feedback as soon as i will ready to explore all this new stuff.

Thanks SWS team!

[Mr. Data]

Originally Posted by Jeffos

Localization:

Ok! I'll upload a template LangPack for the next beta then! Especially since EVERYTHING is now localized
For the merge, it is better to have separated SWS.de & REAPER.de langpacks (because one day we might be able use them separately) but in any case, no, nothing special, your translations will be preserved.

Thank you very much!!


-Data

[jnif]

Originally Posted by Veto

hey gofer,
if you like have a look at my thread here or alternatively have a read through this. Sorry have to go now
see ya

Or use context manager and 'with' statement. See my undoable example here.

jnif

[fingers]

The decorator and context manager pretty much the same. I actually prefer the jnif's context manager more than the decorator as you don't have to write a function for your script and the code is a bit easier to understand. The nested functions in the decorator are a bit of a head fuck.

[Anton9]

Hey Fingers,

I just had a peek at Revision: r884 and all I can say is WOW!!!
Thank you so much.., this is going to make manipulating MIDI such a delight.., dare I say EPIC even.

[Jeffos]

^^ yep here comes the fest!

Also, in the next build, I changed some APIs to use "FastStrings" as proposed above
=> tighter memory allocation + get rid of string length limitations for ReaScripters
=> feedback welcome!

Added some other funcs too.. including a SNM_GetSetObjectState() with a magic "wantMinimalState" param for read-only applications
Can be useful: I added that after I totally hallucinated on how Python is slow (and I don't even talk of running scripts inside REAPER here). Wow! this is for sure the slowest "language" I've ever seen => good luck guys!


@Veto:
Nice func wrappings! If you come up with a "generic" solution many people agree with, we could deliver it in sws_python.py, let us know!
Rmk: if we do that, it can't be part of the HTML doc though..

[Viente]

Originally Posted by Jeffos

Python is slow (and I don't even talk of running scripts inside REAPER here). Wow! this is for sure the slowest "language" I've ever seen => good luck guys!

So that delay between running the script and its execution happens because of this? Or is it becuase its not compiled to machine code?

[Jeffos]

build #6 is out: http://code.google.com/p/sws-extension/downloads/list

.. and for those who don't care about reascript/localization stuff, there are other goodies incl. new tempo actions/tool and auto-color for markers/regions from our new project members: Breeder & Brado231, thanks guys!

Localization: please, make sure you have downloaded the new SWS Template LangPack v2.3.0.6 edition 2

@Viente: I have some idea about the perfs but it would be like "venting".. I must also say the tests I did to evaluate python's performances were radical (I am a bit maniac when it comes to "what is fast or not" ).

@Veto: simple + efficient = great stuff!
I guess we won't get some feedback either but I like the idea very much, it would really help for some upcoming stuff too. Will do!

[Reno.thestraws]

Auto color for region and markers! Ooooohhhh yeah!!!!!!!