req: AUXDATA field in Chunks of Tracks , Lanes, Media Items and Automations Items

[deeb]

If MediaTrack, Media Items, Envelope Lanes, Automation Items had a AUXDATA field in their chunks, Basically working as "local" databases in which scripts could use to store some relavant information and rely would make possible and easier a lot of kind of scripts.

So my request is that and the API function to get/set this Data for each of them.

edit:
Also would be nice to have something like ExtState for each one of them.
so that different scripts can use it without messing others.

per example for media Items:
GetMediaItemState(const char* section, const char* key)
SetMediaItemState
DeleteMediaItemState
HasMediaItemState

[Xenakios]

Originally Posted by mpl

SetTrackSendInfo

He means he wants to store custom per-track data, not aux sends. Anyway, that should already be possible with SetProjExtState and GetProjExtState. The track GUIDs could be used to generate the key names for those functions. (This approach has some problems like when removing tracks, the custom data won't automatically clear from the project state...Also copying tracks can end up problematic.)

[deeb]

Originally Posted by Xenakios

He means he wants to store custom per-track data, not aux sends. Anyway, that should already be possible with SetProjExtState and GetProjExtState. The track GUIDs could be used to generate the key names for those functions. (This approach has some problems like when removing tracks, the custom data won't automatically clear from the project state...Also copying tracks can end up problematic.)

This make scripting much easier for a wide of application without the hassles you described. Better for scripting == better for all users

[Xenakios]

I'll propose to make it even more powerful and allow extensions and scripts to also store per-item and per-take data... (The available workarounds really are terrible at the moment...)

[deeb]

Originally Posted by Xenakios

I'll propose to make it even more powerful and allow extensions and scripts to also store per-item and per-take data... (The available workarounds really are terrible at the moment...)

thanks! awesome idea! opens a lot of possibilities wawaweee

[deeb]

this one opens a lot of possibilities for community scripts and extensions so one bump!

[Meo-Ada Mespotine]

I'm all in with that one....

[juliansader]

+1!

I have long wanted to submit a similar FR for Automation Items.

Scripts such as my LFO Tool could then store an AI's curve data inside the AI itself, recall it whenever a user wants to re-edit the AI, and the data won't get lost during moving and copying.

[deeb]

Originally Posted by juliansader

+1!
Scripts such as my LFO Tool could then store an AI's curve data inside the AI itself, recall it whenever a user wants to re-edit the AI, and the data won't get lost during moving and copying.

ahh cool ! : ) and many many many other things i am sure

[juliansader]

Media items actually already have "Item notes", with chunk field <NOTES.

[deeb]

Originally Posted by juliansader

Media items actually already have "Item notes", with chunk field <NOTES.

i wonder what is the purpose! and if is this recent

[deeb]

I reminded to add to the request a section / key like it happens with GetExtState
so that different scripts can use it without messing others. Also would be nice all the complementary functions.

per example for media Items:
GetMediaItemState(const char* section, const char* key)
SetMediaItemState
DeleteMediaItemState
HasMediaItemState

Also Markers would be nice in the list too, but apparently they have a different way of being saved

[juliansader]

Originally Posted by deeb

i wonder what is the purpose! and if is this recent

As far as I know, item notes have existed since the early years. In the case of empty items, the notes are the text that is displayed inside the item. In the case of other media items, the notes can be anything. I sometimes use it to temporarily store info for my scripts.

Strangely, there is no native API function to access the notes. Scripts must either use the state chuck, or use the SWS function ULT_Get/SetMediaItemNote.

Originally Posted by deeb

so that different scripts can use it without messing others. Also would be nice all the complementary functions.

If scripts share the same item notes, they can mark their own part (using "*****script name*****" or whatever), to ensure that they don't disturb other notes.

[deeb]

Thank you!

Originally Posted by juliansader

If scripts share the same item notes, they can mark their own part (using "*****script name*****" or whatever), to ensure that they don't disturb other notes.

yes, but this way forces a good practice imo, and so not so susceptible to be changed if other scripts don't take that into account properly, just that, like happens with GetExtState.

[spk77]

This would be very useful!
+1

[deeb]

Bump!

[Meo-Ada Mespotine]

For MediaItems and MediaTracks, I made some functions to do that:

Read the following and the chapters following after that:
https://mespotin.uber.space/Mespotin...kItemExtStates

AutomationItems are still missing, but should be possible to do as well. But I need to research it a little first to be sure.

[deeb]

Originally Posted by mespotine

For MediaItems and MediaTracks, I made some functions to do that:

nice mespotine and thank you! it can indeed be very useful but i think it is not really the point of the OR and i think using exstate it is much limited compared with AUXDATA written in track/item chunk for example copying tracks/items in same or in another project won't copy this values. So i think it does not full fill the request since it is something different and so i think REQUEST still open and valid!

Thank you!

[Justin]

Looking at adding this!

[juliansader]

Yay!

Automation items are not yet included in the chunk, but I hope that it would be possible to add some kind of AUXDATA or "item notes" feature to AIs too.

As an example of an application: The LFO Tool can automatically recall the LFO shape of an AI, but only by using the AI's ID number. If the ID changes, as happens when copying without pooling, or moving to a subproject, to LFO Tool is stymied. Auto-recall would work much better if the LFO data could be saved within item notes that get copied with the AI:

[deeb]

Originally Posted by juliansader

Yay!

+ 1000!

[Justin]

Now available (for testing anyway) in +dev0326. Post any results in that prerelease thread...