Live set location
How can I report the location of my live set?
a mobile with GPS and blutooth? :)
not sure if the file path really is part of the song somehow, the SONG section mentions paths but i am not sure what that means.
https://docs.cycling74.com/max5/refpages/m4l-ref/m4l_live_object_model.html
The root path of a song is 'live_set'. From there you can navigate within the song but not anything outside like the file path.
this question has been asked many times here, no one seem to know how to use
get_document Returns: the current live set.
ha, ha, happy not to be live user...
'get_document' just allows to access the current live set from the application root path 'live_app' instead of using the path 'live_set' directly.
In other words there is no way to ask live for the name and path of loaded project in order to
for example load stuff like samples or picts into m4l device ?
did you notice how it said "canonical path" in the reference.
it should be followed by an apology explanation.
The term "canonical path" is explained in the Live API overview chapter.
it is something which is extremly useful when you are on an operating system which forces you to install live under /user, and you wish to find out about the relation between the live set and an arbitrary file on a higher level or another disk. ^^
That is a joke - about not being able to retrieve OS infos ?
vanilla max objects like gestalt, not to mention use of shell,
node.js and other 3rd party externals able to talk to world outside of
Live's little sandbox.
also path to thispatcher to get the absolute path to it's location,
and all messages to max seem to work
maybe me and the OP are wrong about that, but it could easily be that it is not so easy to get the live project files´ real path in order to find a subfolder beside it or whatever he wants to do.
if it is the case, one is probably best advised to ignore my stupid jokes - and possible workarounds involving java or shell, too - but instead change your own strategy how and where you store your files on disk.
i am working with a lot of different programs and i never had the need to know where the application is. well, except for max/msp. but i know that the max to max is ":", i dont need to get it programmatically. :D
So, I recently found the need to know the real file path of the live set project folder.
Here is the only solution I was able to come up with (an abstraction: och.livesetdir). And here a basic example device showing it in action.
I honestly think it is pretty ridiculous that I had to go to this extent: create an audio track, record a clip, retrieve file path from clip, then cleanup a little bit... but hey, just vanilla Max!
Just posted another workaround via MIDI Remote Script @
https://cycling74.com/forums/can-i-get-the-file-path-of-the-current-live-set-using-max-for-live/replies/1#reply-62e0ef674609d95f0259f7d2
Why not use opendialog folder in one m4l device,
select current live set and use the path for whatever it is needed
instead of creating tracks, recording , and all that complications ?
or here, trying to chase which live version is the one in use,
that crap leaves preferences of all ever used versions on disk,
now guess which one is the running one.
Some even use versions 10 and 11 for whatever reason at same time.
to that read log -
Open live, make new set and save it. Now try to get the path of that set by reading the log ?
Nothing will come out, because that anyway useless logs don't get updated when new set is stored ,
even if one works all day long on it.
if so complicated, why not scan the system for any disk activity
once live started and monitor live's read-write activities,
and use path to last .als file used ?
fseventer on mac or procmonitor on windows...
The log-based system works great for my needs. The functionality I'm building out is substantial enough that it's not a big deal for a new project to require an "initial setup". It's not even that bad, just clicking `File > Open Recent Set > ___TheNewSetThatWasJustSaved__` is enough for the new path to be detected.
I also ditched the multi-version compatibility from the example I referenced, as I'm only running 11, so the log retrieval is absolutely accurate. Even if you needed multi-version compatibility, it would probably be pretty easy to implement with a quick check against the API.
The M4L dialog approach isn't ideal because it requires several steps to initialize, and then has to be updated manually if the project is moved.
The disk-activity approach seems interesting, I'd definitely be interested to check it out if anyone works on it, but as mentioned - the log approach has been 100% reliable for me so far and is the fastest / least-effort-per-set approach out of all the ones I've seen implemented so far.
Would a disk-activity scan have same immediacy as the log scan? The order of execution of the log being written to and loading sets is consistent, so scanning the log can be done immediately & synchronously during `ControlSurface.__init__` with Python's built-ins, without any noticeable impact on load time. Haven't tried executing external processes from a RemoteScript, so I'm not sure what kind of performance impact that might have.
Hi, another interessting workaround. Unfortunately with this little flaw. How does the script know when it's time to rescan the log?
Scripts are disconnected and reconnected when you open a new set, so the log will be rescanned automatically if you have it set to do so during script initialization.