i have this little script that talks to ableton live by saving a wavefile to /tmp/ and then loading it. but since the name is always the same, ableton live just decides, it's the same file, regardless of content.

what should i do so that the plomjaa_ableton.wav has a random say 3 digit hash, and for that same hash to go to the exec open command, please?

@esaruoho

This post intentionally left blank.

@oid
hi there doesn't seem to be a response, just a quote?

@whale-av said:

@esaruoho

thank you. that was wonderful. this really really helped! i think this coupled with TouchOSC control over both PD and Ableton Live is really something i look forward to whipping out when it's time to have another HLER jam-session with my mate.

@esaruoho I have no idea what happened there, best guess I palmed the trackpad. But since I am in this thread now, why not sequential numbers instead of a random number? Random number gen will eventually give you the same number twice in a row and do so at the most inconvenient time unless you go through the effort to make sure it can not, simple counter will always be a different number. If you are going to stick to random you can insure it will not give the same number twice in a row with the addition of a [trigger] and a [select] like so.

Or you can just replace the random with your standard [f ] -> [+ 1] counter.

Edit: Thinking on this, why not use a time stamp instead of random or a count, this will get you a record of your edits through a performance in a sane way that can later be referenced which could be useful and you already have the timestamp logic worked out elsewhere in your patch.

@oid Yes, I realised afterwards that [random] could be problematic.... and thought to add [change] but your solution is easier to implement.
Time is a good idea, but will be a little difficult to read.
A counter would be best I think.... it just needs a storage system to keep track as the patch is re-opened.
David.

@oid said:

Edit: Thinking on this, why not use a time stamp instead of random or a count, this will get you a record of your edits through a performance in a sane way that can later be referenced which could be useful and you already have the timestamp logic worked out elsewhere in your patch.

actually, yyyy-mm-dd_hh_mm_ss would be pretty good. just not entirely sure how to create it reliably.

@esaruoho There is probably an external for getting date and time but I would just use [command] unless I needed something lighter since it saves me from having to find a suitable external and it also lets us get the date in exactly the format we want it. This may not work on Windows but should work on most anything with unix heritage including OSX which I seem to recall is what you use? You can open up terminal.app and type man date to get other formatting options.

You could also use performance time and derive that from you master [metro] and some simple math to get beats and bars or what ever you desire instead of literal time, has some advantages but would require more work and possibly some reworking of your patch. This is a difficult one to answer without more knowledge of your patch and the way you use it.

Edit: That fails, this works, will leave the above since it could be of help to some. It seems the problem with the previous is that [command] breaks the right to left depth first execution (probably a good thing), pd does not wait for [command] to finish before going to the next step in the trigger so the previous time would still be set on the cold inlet of [list] for the next go around. I should have just read the [command] helpfile, as usual.

came up with a naming & storage system for wav files using a text file in the same folder as the pd patch that has some logic to let you know when its missing/hasnt been made yet - so you know to check the wav files in case it would overwrite anything.

just ignore the unfinished recorder I was playing around with, I wanted it to warn about overwriting but it turns out theres a lot of new stuff for checking files in vanilla 0.54. also still not sure about some edge cases like big files, slow computers with it but the text is solid.

be pretty easy to modify this to get a random value based on its size too