Metering woes for my Sidechain Device :(

    Jul 29 2013 | 8:13 pm
    Hi there, I really hope somebody can think of an answer/work around to my problem.
    I have built a m4L Sidechain Device...... where parameters (On/Off device was my primary idea) are controlled by audio input levels...... there being level = 1, and no level = 0.
    Everything works fine except for the fact that Abletons track level (where the control data comes from, slowly fades down once the audio has stopped. (this can be easily tested; If you get any long sound, then crudely chop it and leave some spaces so there's no sound)
    if you look at the level meter attached to the plugin~ object, this responds correctly to sounds, Abletons own holds..... i've also tried the output_meter_left/R aswel and they to are no good.

    • Jul 29 2013 | 8:20 pm
      And now I can't even post the copy compressed code? aaargghh
    • Jul 29 2013 | 8:37 pm
      Heres the .amxd
    • Jul 29 2013 | 8:39 pm
      What is going on? it just says server error every time i try to paste the compressed code
    • Jul 29 2013 | 9:09 pm
      Fingers crossed..... i've pasted the code for the patch into a text edit file;
    • Jul 29 2013 | 9:58 pm
      hi mate,
      sorry to hear you're still having troubles with this patch after the facebook session the other week.
      yeah, ableton track meters have some smoothing on them, especially on the release/when falling back down to the bottom.
      if you get your data from the ableton track meters through the live api then that's the best you're going to get.
      i really think you need to switch to monitoring the audio coming into an m4l device, rather than using the live api.
      the test patch in the tutorial should have you set up with a working device pretty quickly.
    • Jul 29 2013 | 10:28 pm
      Cheers Pal, I'll check it :)
    • Jul 30 2013 | 3:29 pm
      i finally get what you mean MYR :), i thought the plugin~ would output signal data from all tracks but it only outputs data from the track that the device is in :)
      i can then use a send~ and just put that device on the track i want to sidechain from.
      Its just a shame i cant include it all in one device, like the one i designed, where you can select the track with a variable.
      because, Plugin~ doesn't take any arguments
    • Jul 31 2013 | 11:29 pm
      yeah, in max 4 live you can only get audio (or midi) from, and output audio (or midi) to, the track your m4l device is placed on. you use the [plugin~] and [plugout~] objects to do this.
      we're hoping to get the option to get audio into and out of an m4l device from any track, but there is no way to do this yet.
      however there are some workarounds:
      - if you just want volume you can use the live api to monitor a tracks volume level. as we've discussed this isn't really useful for you as live gives you a smoothed value which isn't accurate enough for the sidechain device you are building.
      - you can create a small, simple m4l device which you can drop on any track. it will sit on that track and monitor any audio that comes in from [plugin~] getting data from it (volume, transients, frequency, whatever you want). you can then use a [send] or [forward] object to send information about the audio to your other devices which want to use it.
      - using the live api you can change the audio input and output of a track on the fly. so you could build a device that, similar to the one in the point above, sits on a track and analyses the incoming audio from [plugin~]. this device could also have an option to select what audio was coming into it by changing the audio input of the track using the live api.
      unfortunately you shouldn't really use [send~] in m4l devices. due to the way m4l works there is an unpredictable delay, or amount of latency, when sending audio between m4l devices using [send~] and [receive~].
      if you want to send audio between m4l devices you have to either route the audio using abletons built in track mixer options, or translate the audio data into normal max messages running at "control speed" and send them between devices using [send], [forward] and [receive].
      as mentioned there will always be delay when sending data between devices, using [send] or [send~], and for a sidechain device to be really accurate you need to make it work at "signal rate" using msp objects with a "~" after them. this is why pretty much all sidechain devices created in m4l so far don't use [send~] or even [send], they do the work at signal rate on the track the are on and then send the data to a device parameter using the live api.
      have you checked out the "Envelope Follower" max for live device that comes as standard with live 9 suite? it effectively does what you want to do, and is a good example of how to go about doing it. i'm sure you could think of some good things to add to it, or incorporate what you've got of your device so far into it. let me know what you think after having a look through the device, i think it should clear up some things and show you a good example of how to achieve what you want to.
    • Aug 24 2014 | 1:54 am
      Hey Myr,
      I'm looking to get into making some devices that utilize some pretty extensive sidechaining and I'm also looking for the best way to go about it. In regards to Envelope Follower, i have Live 9 Suite but it's a license transfer and an upgrade and i can't seem to find that device on my computer. Is it something i can download somewhere for free or no?
      I think i understand what you're saying as far as sending data to a device parameter: basically automation, right? Just send the data to a dial or box that has "Automated and Stored" selected in the Inspector. If that's correct, how then to receive it?
      Thanks for any help as i continue my quest for information!
    • Aug 24 2014 | 11:25 am
      To Dannyflint : The audio versions of send and receive objects don't work in Live, they involve a variable latency, this is clearly stated in the MaxforLive vs Max comparison chart.
    • Sep 05 2014 | 10:29 pm
      In case it helps anyone in the future: I finally discovered that Envelope Follower is part of the Max for Live Essentials pack and can be downloaded here
      Upon opening up and dissecting the device, i found that the "receiving" of data seems to be conducted via a live.remote~ object buried in the rather complicated MapButtonLFO.maxpat abstraction. i guess i'll just attempt to hijack it and mod it for my own purposes...