waveforms in ableton

  • Hi everyone,

    I've been designing a personalised patch for performance and DJing using Ableton, Max for live, monome and livid code. All going well so far, apart from one issue I'm having with CPU.

    I wanted multiple waveform displays of whole soundfiles - like in Traktor - and of course ableton doesn't offer this. So I've been using a workaround - a waveform object inside a max window that is linked to a buffer. Everytime a track is selected in ableton, max reads the filepath of the track and uses this to replace the buffer contents. So the waveform is updated and this all works fine.

    The problem is that loading these files into the buffer mid-set uses up a lot of CPU and occasionally causes stuttering in the audio playback.

    Is there some way I could ease the CPU using defer objects to set this as a low priority? I woukd guess not because whenever Max gets round to loading it in, the process will require the same large amount of strain on the system. The only other idea I had was to have many buffer objects present in the patch all the time, into which every soundfile I plan to use is read on startup. Would flicking the waveform between these buffers cause similar problems?

    Or do I just need to fork out for some RAM expansion? It's a 2012 macbook pro with 4GB but maybe this isn't enough?

    Any advice you lot could offer would be massively appreciated.

    Thanks

    Chris

  • the 'correct' (or 'traditional'?) way of doing this is to create waveform buffer files like ableton's .asd or traktor probably has it's own format too. then you do the big calculation ahead of time and you don't actually have to load the file into RAM at all when playing. obviously this approach requires a great deal of additional patching to create the data structures and then you still have to run the analyzer beforehand. maybe you could get your hands on the ms pinky max patches as i know they have a method to do this.

    alternatively there's a few things you could do.

    the idea of loading all the samples into RAM at the beginning of the set would definitely decrease the CPU load that occurs when switching files, but you obviously will have the issue of RAM usage. remember that buffer stores everything as a 16(or24)bit wave file internally, which could be upwards of 1GB if your set has more music than your planning to perform in that performance (or if you're djing 4 hours+!)

    loading audio to RAM in advance will help with CPU spikes, but changing the buffer file associated with the waveform creates another CPU bottleneck as it turns the RAM into an average calibrated to the display size.

    if you can afford to devote that much RAM to waveforms then it'll be the most responsive approach (even more than the above analysis file approach). the best thing would be to create a giant patch with a maximum number of waveform objects in it already loaded and analysed. then you just move a pointer around that sets offsets inside a bpatcher to view the appropriate waveform.

    it might be an interesting experiment to try loading the audio files to RAM as they are selected (as you are currently i believe), but NOT display the waveform. see if you still get the CPU spikes (i'm assuming you will). If you still get spikes then i'd say just adding all the files to RAM at first will be a good solution, otherwise (as in not drawing the waveform stops the spikes) you'll need to create the giant multi-waveform patch mentioned.

  • wouldnt it be great to use the ableton als files themselves to recreate those waveforms? i dont suppose ableton has ever released the format specs for als files though, close mouthed bastards that they are :]

  • @lokey yes that would be great. One of the many things I expected to be integrated in m4l between the two programs.

    It would also be useful if the waveform~ object in max gave the option of saving the loaded waveform as a much smaller sized filetype like an image file, to be loaded again later using much less cpu. but as far as I can see this isn't possible (yet).

    @galapagoose thanks so much for all your suggestions - I'll give these a try tomorrow and let you know the result.

    Any other suggestions welcomed!

  • @galapagoose so it looks like the actual drawing of the waveforms is not using up a lot of cpu - I tried loading all the soundfiles in the set to separate buffers and flicking the waveform between them with a 'set' message doesn't cause any problems, very quick in fact.

    As predicted though, problem is using up that much RAM to begin with, particularly cause I want a lot free for other loopers/effects etc within Live. Also, even when using a polybuffer, it takes a really long time just reading in the appropriate folder of soundfiles...

  • i know your pain. this is the reason mlrv takes so long to load if you have a big set with lots of sound files. i'm afraid the only solution to both of your problems (ram vs cpu usage) is to roll your own, which is no small feat...

  • @lokey what do you mean format? you realize if you 'gunzip' a .als file you can see its contents?

  • Ok think I'm going to bite the bullet and buy the Ms Pinky patches for this. Looks like you can only buy the whole bundle though, whereas I only really want the M4L element - anyone know if/where it's available on it's own?