Bouncing of audio files


    Jul 02 2020 | 10:50 am
    I'm bad at mathematics and can't create it myself, so I have to ask: Is there any way in Max to create a bounce command as they exist in DAWs? That you take an audiofile add a filter of plug-in and then bounce it instead of re-recording it in realtime?
    Thanks for any hint.

    • Jul 02 2020 | 3:32 pm
      it is a bit more complicated in practice, but in theory it is simple: - switch to nonrealtime audiodriver - start task - if task is finished go back to your other audio driver again.
    • Jul 02 2020 | 3:41 pm
      Hi Roman Thilenius, from having seen our name many times in the forum I know that you are a real crack, not like me, I am OK but certainly not a crack. I am afraid that I cannot get anywhere. I do understand to change the driver and I know how to do that, but what exactly is the task. How would that patch look like? Maybe something like: have a playback (sfplay~ or so) connect to a filter (or whatever) and connect to a record (sfrecord~) then run all at high speed? Is that a possible scenario?
      Thanks for your patience
      HP
    • Jul 02 2020 | 9:18 pm
      this question comes up from time to time and i have never posted my abstraction because i am not really done generalizing it enough. also, in cases where the vectorsize matters, it does not yet copy the vectorsize of the original driver when you switch. there are too man variables so i could never decide how to finalize that. it remembers the recently used vectorsize for the nrt though, and of course it resets your original driver to its recently used settings. but i will upload now, then i have found an idiot who can test it for me under Max 8 :) are you on mac or PC?
      nonrealtime
      nonrealtime
      mixdown
      mixdown
    • Jul 02 2020 | 9:31 pm
      ah yeah, and it doesnt yet reset the driver on patch close.
    • Jul 03 2020 | 6:54 am
      Hahaha, I am happy to be the idiot to try it.... I'm on a Mac and I will see if I can deal with your patch. Great
      Thanks for your patience and genereosity. HP
    • Jul 03 2020 | 7:41 am
      Please apologise and I don't want to e a nuisance. But I see what your patch does with the driver, but have no clue how to use this for the task I am looking for, , which is to be able to bounce audiofile not in realtime but faster. How do I implement the speed into this. I tried your patch and loaded a file into play but I cannot understand what the patch then does. Sorry.
    • Jul 03 2020 | 9:43 am
      NonRealTime audio driver is supposed to run dsp as fast as possible. Means instead of playing 10 second long audio file in 10 second time, it will play it as fast as system allows . It can also be used to process stuff that would otherwise be to heavy in realtime. Now the questions is are you having skills to: 1- set the driver to nonrealtime 2- start playback and recording 3- at the end of playback stop recording, store file 4- turn audio driver back to what it was... P.S. I would use buffer based playback and recording
    • Jul 03 2020 | 9:49 am
      you might not see the difference because you have a faster computer than i do. try the following in the example patch: - raise the time for the line message from 8000 to 100000 (left part) - turn nonrealtime on (middle part) - trigger the line again (left part) on my PPC G4 the line object will run about 40-50 times faster than normal in nrt, so that i can hardly se a delay between the buttons at 8000ms. of course for a 1000 ms recording process it does not make much sense to switch to nonrealtime because switching drivers already takes about 1500ms. but for 10 seconds or so it can speed things up. how much CPU is you patch using? if you use for example 25% for audio already, nrt will speed up the processing only for about 2 - 3 times. i use it a lot for copying buffers and then it is only activated when the buffer is longer than 4 seconds. post your stuff if you want, i will be happy to help because that is the way i learn new things myself. (and dont expect any other other drivers than ASIO or macOS-CoreAudio to perform that in/out threadsafe.)
    • Jul 03 2020 | 9:58 am
      ...and while it works with record~, for a "bounce" function i prefer to write to buffers, then export the file. it is just more safe in case the CPU is faster than the harddisk.
    • Jul 03 2020 | 10:12 am
      here it is. only insert whatever you want between play~and record / dac it's up to you to link play and bounce buttons so that they don't interfere, and check timing if needed (latency of processing )
      Save the patch and reopen so that it builds drivers menu
    • Jul 03 2020 | 11:18 am
      Hi,
      I think I got it now, thanks for the additional info. Here it is, so far without any filter, but I placed a bogus object instead and it all works. Many thanks, HP
    • Jul 03 2020 | 12:41 pm
      Hi Source Audio,
      thanks that's also a good solution, and yes, it's pret a porter... ;-) Many thanks and all the best and stzay healthy HPK