StateChunks: change in filename of source with Reaper 6.33 (FIXED)

[Meo-Ada Mespotine]

In this thread, Aurelien noticed, that the way that sourcefile in itemstatechunks is stored has changed its behavior. It used to be that the filename was always enclosed in " but now it seems to follow the scheme of other strings in statechunks, to use " only, when there's a space in the string somewhere.
Even though I can add this detail to my Ultraschall-Api easily, I think this could break old scripts, that were expecting it to behave always with " enclosed.

https://forum.cockos.com/showpost.ph...&postcount=719

Tested on Windows 7 Reaper 6.33x64

[Justin]

...of course those scripts will need to be updated to support quotes in filenames, too.

We can easily change it to always use quotes even with no spaces, but not sure what the best route is...

[mpl]

Originally Posted by Justin

...of course those scripts will need to be updated to support quotes in filenames, too.

We can easily change it to always use quotes even with no spaces, but not sure what the best route is...

Best route is to prevent chunking from developer side as much as possible
An API way of editing things would solve lot of chunking mess (including parameters Modulation/Learn, FX name or (available) parameters access, project header stuff, spectral edits etc).

[Meo-Ada Mespotine]

We can easily change it to always use quotes even with no spaces, but not sure what the best route is...

I would prefer to keep the old way.
There are plenty of scripts still being in use, done by scripters who left the community or are even deceased. So many of them have a low chance of being altered for the new changes.

Any chance of including such changes into dev-changelogs in the future?
This one was discovered by accident and most scripters would probably miss it and therefore not know, that scripts need to be updated.
I was lucky that Aurelien did the research on that one and found that, otherwise I would have probably spent weeks finding the issue in my code... :/
Having a hint in the changelogs would be very helpful in these cases.

[Justin]

Originally Posted by Meo-Ada Mespotine

I would prefer to keep the old way.
There are plenty of scripts still being in use, done by scripters who left the community or are even deceased. So many of them have a low chance of being altered for the new changes.

Any chance of including such changes into dev-changelogs in the future?
This one was discovered by accident and most scripters would probably miss it and therefore not know, that scripts need to be updated.
I was lucky that Aurelien did the research on that one and found that, otherwise I would have probably spent weeks finding the issue in my code... :/
Having a hint in the changelogs would be very helpful in these cases.

The next +dev build will have it go back to " quotes when possible (almost all cases).

The 6.33 change was in the +dev builds for a while, as

 + Project files: allow filenames to contain quotes on supported platforms

(not super-obvious but there)

[Justin]

Originally Posted by mpl

Best route is to prevent chunking from developer side as much as possible

Agreed Though scripts that do use chunks should use a correct/compatible parser too...

[mpl]

Originally Posted by Justin

Agreed Though scripts that do use chunks should use a correct/compatible parser too...

Would be nice to port native parser into API, like... forward and back chink to/from multidimensional lua table?

[Meo-Ada Mespotine]

Originally Posted by mpl

Would be nice to port native parser into API, like... forward and back chink to/from multidimensional lua table?

+1 would be a dream come true

@Justin
Thanx

[X-Raym]

@mpl
It worth mentioning that we (mrlimbic and I) released a RPP lua parser which is really solid, using objects :


https://github.com/ReaTeam/ReaScripts/wiki/RPP-Parser

[TonE]

Originally Posted by X-Raym

@mpl
It worth mentioning that we (mrlimbic and I) released a RPP lua parser which is really solid, using objects :


https://github.com/ReaTeam/ReaScripts/wiki/RPP-Parser

This parser might be useful if it works with midi/osc mappings correctly. Ultraschall api started adding functions for it lately, not working fully yet, according to my tests so far. See https://github.com/Ultraschall/ultra...aper/issues/13

The idea is creating line based, csv export and csv import for all midi mappings in .rpp, but listing all parameters, also the non-mapped, so those can be changed externally in Excel or emacs, if wanted so, then reimported back, getting all the new mappings directly. If such a system would exist (csv export and csv import of all midi mappings in .rpp), one can start creating scripts for auto-generating such mapping csv files based on self-defined rules.

For example if you have a set of hardware midi controllers, and you have a list of all your outputting values, you would simply fill your target parameters of your .rpp to your hardware generated values. Ready is your groovebox. Hardware knobs, faders, controlling something in your .rpp, exactly as you want, without having to do hundreds or thousands of clicking, mapping steps.