[solved] Basic Filesystem operations

Hello.
I'm not so familiar with JS.
I'm looking for help with file operations.
I can't use nativeRequire inside onCreate or onValue.

Open Stage Control can read and write files itself: there are reserved remote control commands /state/save and /state/load, I can even load the state from a file with a simple stateSet('path\name.state').
But I don't see how to save like this in a similar way.

Continuing the topic of this discussion

It's very easy to get the state of an individual tab or UI element via stateGet() and converted to a string it's a ready object to be written to a .state file for later loading as a preset.

But, nevertheless, in general - what is the right simple way to save a string to a file or load it from a file inside the standard onCreate or onValue functions?

The interface even has a widget for selecting the path to the file, and there is also browseFile() with its good description, but no examples or hints.

Thanks.

1 Like

Wow if someone could suss this out I'd happily pay them for help... Would transform my rig completely having a decent presets system.

These operations must be performed in a custom module based on osc messages sent by the client apps and caught by the oscOutFilter function. In the thread you linked I posted another link to an example demonstrating this very use case.

1 Like

Yes, this is the solution in some way.
I can load any stuff in custom module but i can't access it's functions from another widget's code according to incapsulation.

So we need to born dummy osc message each time we need to save some data in file.
But it works with no doubts.

Nevertheless, I think you did the right logic to prevent any kind of user's mess and chaos.
If I want to work with filesystem, I can work with it. I just need to pass a higher entry threshold so as not to shoot myself in the knee.
It could very well be a nice structured set of commands like
/save {data, path}, /load {path}, /scandir {path}, etc.

Just worried about kilotons of data flying through the local port in case of saving complex states or patch lists.

Indeed. However it could be an idea to add a dedicated way to communicate with the custom module to prevent confusion with osc messages that are meant to actually go out of open stage control (although in the end it would use the same bandwidth). I'll put a pin on that for further tinkering.

That's kind of the idea, I'm not very confortable with the idea that one can mess with its harddrive just by loading a random json session file, loading an extra custom module adds an extra step and a chance to realize what's actually going on since it ought to be human readable.