How to load sample from Ableton Factory Packs into buffer~?
Hi,
Question as in the title: how should I load samples from the Ableton Factory Packs into a buffer~ in a Max for Live device? One option is to add a live.drop object, have the user select and drag a sample into that, and then use that. This works, but requires the user to set up the device. I'm working on a device that will use quite a few samples, so having the user select each and every one seems unnecessary -- especially given that the device is designed to work with a specific factory pack.
Trying to do this without a live.drop object results in two problems:
1. Path to the sample. On my machine, these samples are stored in /Users/edsko/Music/Ableton/Factory Packs/pack/.../sample.aif, but of course this will be different for everyone. Apart from the absolute path, however, every other suffix of this path (just "sample.aif", just "Ableton/Factory Packs/.../sample.aif", or any other combination, does not seem to work.
2. Even when buffer~ can find the file (when I specify the absolute path), it refuses to load it, "cannot open parser for this file" -- even though the very same sample works just fine when I drag it into a live.drop. (Whilst trawling the forums to find solutions to this problem, I came across https://cycling74.com/forums/buffer-could-not-parse-aif-err-1 which seems to suggest this might be because the .aif files have some kind of protection that they cannot be used outside of Live..? But I am trying to use this in a Max for Live device..
Any help and/or pointers would be appreciated,
-Edsko
Protected Ableton aif samples won't load into buffer-
You would first need to "unprotect* and repack them
It works just fine with a live.drop though; so I guess that must be doing that "unprotection" implicitly? So does that mean impossible to write a M4L device that uses samples from Live packs directly? :(
I am not sure what the problem is.
If the sample is protected aif, you can find out by simply trying to open it in another app.
like audio editor or max sfplay etc.
It will not work.
What restriction to live devices is, I don't really know.
But at least in Live 10, one can't use any
protected aif sample to load into buffer,
being max standalone app or in max4live device.
I want to bump this a bit as I have the same issue. In response to the previous post: it seems the Live.drop object does create some kind of temporary address (I'm not sure the exact method or term) for protected samples such as in factory packs so that buffer~ is able to load them. I can confirm that you CAN load protected samples into the buffer~ if using Live.drop
My issue (maybe similar to OP) is that I am making a device that you can drop 1000's of samples and so I store the names in a dict and can't use Live.drop and therefore the users cannot load in protected samples in my device (ie from factory packs) :(
I've done some tests and it seems when you send a "clear" message to live.drop, the temporary address it creates is lost, the same happens when you drop subsequent samples into Live.drop (it releases the previous dropped samples' temp address). So unless I want to have 1000's of live.drop objects in my device I cannot use it (and similar projects wont be able to).
Is there any way to load protected samples into the buffer without live.drop? Does anyone have any more info about this? Thanks!!
I found elsewhere on the forum Source Audio said this:
"... some samples from Live packs are copy protected, mans are not real aif files but some encoded format only live can cope with. You can try to open it with any other audio player, or even with hex editor to look for valid aif header in the code."
This makes it seem a bit grim to do this without live.drop , unless their final sentence holds a possibility
This is quite problematic thema.
What I believe is - this TEMP- etc string, having sample name at the end is only a reference to that protected sample.
Sample itself gets loaded into buffer without getting written to disk.
At least this is so with short samples I used for testing.
This unique TEMP id for each sample - it matters where sample is installed,
if you digg one sample from the pack an copy it elsewhere,
id will differ from original one.
If you drop on both live.drop and dropfile, you get both : TEMP string and absolute path to protected sample ...
which can be used to send write message to buffer~ and so make the sample free.
Another idea is to autopopulate umenu with absolute paths to samples and load them through set message to live.drop
and into buffer.
Hmm ok I think from what you said I might be able to do this when loading a preset (non presets work fine because they can go through the live.drop when loaded, its preset recalling that is the real issue) because I am working with 100's of samples going into a polybuffer:
1. Store all the paths in a dict that can be recalled correctly as absolute paths
2. When preset loads don't just send them all to the polybuffer directly, but instead go through a live.drop object internally with the set message as mentioned
I think that should work in my device (??) because once loaded in the buffer doesn't matter if the live.drop releases the reference. Thanks for the spark!
If you need to use several samples at the same time, how about droping a live.drop inside of a poly~ patcher? One sample per voice that can be played simultaneously. But you would be limited to 1024 samples (the maximum amount of voices a poly~ can handle).
I think I'd definitely prefer what I described in my last response (a single instance of live.drop that is used just before appending samples to a single polybuffer) over having 100's or 1000s of live.drop instances. Actually having 100s or 1000s of any GUI object is something id personally avoid
If it works that way, then good!
I agree about avoiding using too much UI objects when possible, but I believe there is no performance loss compared to non-GUI objects when they are simply not dispayed, which would be the case with what I had in mind.
A while go I tested loading of protected aif samples from live packs into polybuffer~ using live.drop -> append $1 message.
It allways crashed after loading few samples.
On the other hand, loading into single buffer to rewrite thousands
of samples in a batch processing manner, worked without problems.