Live API observe track output for metering _ need help please
i try to build a meter device that show me the output of four tracks. at the end the whole meter is meant for open in a floating window, but that is another story.
at the moment my problem is that i have no correct displayed meter. it looks like to slow and not right scaled or something but thats only a assumption.
i used the live API to observe the signal from a track and i get a signal with a value between 0. an 1. . the big problem is, that this signal is not correct interpreted by the meter objects (max meter, live meter). so i tried to translate the signal with this math formula: expr 20.*log10($f1) do get a db signal, but still it doesn´t work proper.
another thing is, if i turn up the volume on the observed track the meter have a strange behavior. a similar thing happens if i turn the volume down. the meter raise extreme and show a consistent peak.
I tried my best to find a way by my self but i´m not e very experienced max/msp user but hopefully you can help me. basically i need this patch for a current DIY dj 4 channel midi controller project for ableton. at the end of the day the meter a displayed in an external 7" usb monitor which is mounted in/on the controller. every observed meter correspondents to a physical channel on the midi controller to get a better visual feedback in your dj set. hopefully you get the idea of my patch and somebody can help me.
if you need any further information feel free to ask me.
----------begin_max5_patcher---------- 2566.3oc6bs0aqiaD94jeErF8g1hTCw6R8ss2.JPKZQ6C8gcWDHaSaytxRFR x4jSWrme6khCsibhkM0kH6yldN.wlx1iF9wYF9wYH0Od+cSlk8rpXB52g9Vz c28i2e2c1KUcg6bsuaxl3mmmDWX+ZSlmsYiJsbxCvmUpdtzd8OsNtr.sJSmt Bkk9cl+iJWqPK04EkHBpnTkqxPaTlWKPEqy9j8iy1UtcWIJaosUh9I0zrYEp 7mT4Hc57jcKpjW0msItbMZYV9lcIwSsWobsNewQB9E4tPmqlWhJzqRiSLRp1 MYab470nmzwnsI6VoS+BJa1+w7km9co5knOmsCY5haiyUnYYlaIHX6kiSQEJ kS9KWZtuoyUSq5pZTYtVs.Ulg1U.eC2s9S5x0lN4a5BnYlKpMHVQoNIA9Ewa LZWd1rD0lonhLi9ohMRasJYqQM9El+UcuJW+b0KEpYwleab59QhDcpZd1tT6 vAl5t5xrzxB8+UYuHYZf6xyVMOKIKGF3ClFQvbQzCUuSJXRb06XDIiaeW.56 c+rzcazoIpRqo.1cQKfZFldrBxAIJYBysBQo1+FFT8BNTTSR5EVqFCz+awzI uHdCVsW9A05BoFrw9C9lbsAU+8YIKlT8o+z82W8mG7z3cipnHdk5MFuFTeqJ u7yN6wGsC5OlnVdvN+HbL3z3H11Mq9Sf6cmF3HMCbD.xXR6KXZn8kF.NVzoA N7E.N2GC+hxOuUA26ISPeeGvzT0mLJyafzi7ku.J5K5HkVyJNoxPFIIfYUCf i7zfCoqfyCV.x8wEwOoV7HD33w3Ri2uweFBjd2Ab5tIOZrpJzlPTl.E19r85 V.dnLc0KP3ABdCYfwG2Z0QIS4Ma6QI251dlN351.LmMbFfHQV+ZN9r1cM.Lz 9X28v.CPknYnjgBbDLqUCwZ7DRsVMMANhg0obVb5ptCNMQk4OBjG9KVVC0HJ bA.aatpvHt3RcVZM7AGYiSAAqHAuw1wWblv4vbBf4G4sVg0Uf5Bq9..azlqs Iz8OmmsA828ahglfz.5AHMr6HJV5Pz.mkaG.T5OK.zvg.NCYfgYTCxwGzjd0 Qy+od05Sx5K7RfHAH8R1O64qYt4KNRwfqsfzff7.HIgWcf7u1.64KiiX9K3H g2YbjDVGGOgf7wfL3qXCRLSZ64hdZPRby0.Sz2QCR7WuFjXbMbrGFjNl.Nbr aFjD9ngiKSxL2iCvXttXdbhUvAFNdub6VF6VbyYwVinVnlq2DmrMw7CNFqZJ fJX24LiC6dD0fHvxUzff7.3wgsk5ZirVM.abYEsUK80NQc0tBGaVJNvJsHQu PkeTZcB3rn.xCG+NoYYd3iyNQi3uEobiB1AAKyqC+t4I5sOdfkQqmlyNZfgE U4DOk1R2gfyuLTcpAhdxLVXoA0z.RhYI5cab356ifA3iI5oOBQ53sv6tOB8V xE4XuiFgOKtwBZxD2exF.62vnlrlMRJQs..jfVD2Q3uE9A4tX1VUt4tUG8a. iGzUN2ctJb6H.Q1SpJXHDOVP6NUEF+qXty0fwdvTIhVCE6FQE10eob+CiVVb JXTdIXj5RlEflfKMuKDObHn.2ff7In53wbdqdd47x7CgkMyuO+GTKLSHsR4w bQTvtyY7DMURCjR665BxASnIOmv7gfvEpQxahJpSG3XhOoxmZXCfmoJi6V1Y ntI2slOBVmSPCMDjCPY3DBxG7Tb0cq+SOalwqp1p+MaoY+25zEYeZhmjsry2 6CZ6RBSHeeHvtB26W02IjjO380OL59TKh9l4k5mzketaVwLh0fiWOFQWrhYt kOC0FMpSYsc7xNl4FLqFMzMYKTulR7IfvB8JXMDstDdRK7J.Wbt3bUpRRF1h w.63gJR68fYYCErR8717JxM+ljrU3fe0ubI9WOPkuJDaCqxCsdoQQmEwn2vE 8z.+eYXwDgKsImsdmR1vhINqntgLiqyFFpHmHPdYmMA++6rYVWAfT.u5y6qg YeL70.HQDDdYWMB41wU6rY..8GVGmlpR5HQgHKJDZQDonyDE3.ZRDQMHHex9 RzMQt.5KfRqUY1Srso7GQgzp.rKNgf7AQkW8c6Wvzn.YXDuq7XE0PS2pnDcX u9wfk3ROZ4XsspDA2BQIu.Pi6EPCwA5ON6hCzMb9lXmVd0K1.KZXp0.lP5cs FXA2tEaXsF1E1S1eASv6rW5MStPQI3CTMIbgnF9ZRvvcnpau20j3p6cfCGFu Cf9S+JDWzsjyw0ejgwGnhjhGfhjJ+vsQBvbx4in0qMR.wUfplCy4ynR3G7MR .FSGnI2CE82GQ702NIfMLSZC4CX3mylxuA2GAiSzGnn3uSQev6q.Qeh9PjW2 nOMk6g+UYbd498V9IOngjSg8m7azxZdBaHD.U4Q6q+Y6KBWjaGQDzff7YzY7 1i+MjuwpCfh4F+kA5fdIXtZ+ZYZxomM+9uW4stWI5uYX5xmSG+Qo5GOD1YSu O4VDkZ2ocMuo8t063wcU.UPgIY03dzzQNjeKmpqA7XXxca61C6gsybLLw7OX GAX2Ajlyht7Q.FS940Q.djNsqL3X.ScEq6rkjBi+fcZWY.EBFU5woc8V5vt1 3jAUOTJpLgdbkpDUlGO+GJPACUnLXWQSc0FGSNW7c76YnL6MzRc8UOsSrZc0 0OF6Jx1kOeunbClnWT6EphRc5ARie6KOPFp8kVqWrPkVmo3F8hsYFx7E6qLQ Xk8CCfGBibnUCCwdqrQdnsUgGai11ScB6C.1RUhGYc.ofYljKOzpmJK2GkU1 NkUHXUpGG1tHxP9gV8czV3g1xamxJkTvXDJZFn51V8UYkdnrUazpVosNvT.Q kIgGZMDPK1GCA7n4HYcRtnNIFUmauvIJoc3THrEOYT3DkCkw01puZqGJKtkJ qauQvwU4qEQh.CxpV8MtIwmX4AsSacy0Hfy1WD2sEDp2ppKXeX6bnCELJ8DV 6Lbc8DtzkXOwgV8Ta8wKq53G1po.Bwvp4fTj6x7xwsBk6SeN20Z.5HWD0aY3 BAmc4NBrOsibbj6+jxuBsanmDNtrZ7YtW5npRRenpRaIL4lSU3d5V.OrTNt0 9C6DrC+Otk6T9V4r91VNCEJanLT7gpIF2GplLNYnnZ50jQ7NMYj6I4EWhOzp uJqWr3CFU6chOLJoiKenW4d0fNIGWbxCCswkIqOyLMtXD1mXmjwcgyTeVLJM Zbsk7YnSzx0b5HuIbavVfM5qZEb3QnB20ZL5IDYG6I0NiZG0f4Rqpj81V6mO LfLTyG5Ei.IoOLBBg8U6qZAo5HLDPiAHUGuJw.MzSX2d9BTderfBOBbqak39 dilUBC2GqD2yhqiasumPCGrEJ3U5OaWGgJsKHiBaks8rA48O.jkH5ESmy3lM GeXTE0NpB6SQGmAm8KXicbTKG25S2BRBzIaQfnMbfs6oa4xhg30FWlF+z8+O .HJ.t7B -----------end_max5_patcher-----------
Right, at the end of my synth evening I came across this. Be adviced; at the time of writing me not 100% sober :-)
Even so; I read the story but your patch doesn’t match what you’re explaining. This does:
----------begin_max5_patcher---------- 794.3ocyWssbaBCD8YmY5+fFd10Cfghceq82nSGFArXqFgDCR35zLse6UW.L NEH3jF67hkxpM6d1ydQhG+vcKbR3GAgC5ynugVr3QkjEFYZIKZErvo.eLkhE FEcnjCvpjZojybV1nvAbECW.idNqtfvnfzXAudR40x+QrUl7gRvBLGGz2aOi jY7AO4Gezyuy7kXY5dBaWbEjJs+SdqCV4tDsU+ieP6umLTItRAXITECLbBEN CAB7AHKFKkUDUf.m1IZHlVlQG4zZfm2Ju6f9dPTBPFkTX7gBJCnBgcfHHM3X PMDRnTL5oXFiKwRBmE2kHbFRQPQ5MzJOO2YoZgcheOW0ikbFvjS.6ZFQJjOz PeCpRgp3YBKTnJLLQ0vG2VE3OLoQjDLsWFbXlaOuRNU444.hm0hX+ngAEky1 cQ1axPjRX2qs13IWsI3YiGfDVNe7LtIGM9w7pLnZTSmA4Mm1b3u+vc1csaZV UKKurQHFG7m+SiHnDgbjwDdSNlHTmiQda85lV34uQOn3EGbL3mJ+14TIbz3K mRZ8NEtGIh8GNh6DmyYmpg+RkprG8UNMyYTFQPT0nTcCdytAYmImgt1csgPr iRCs+wl9SQ0nRP9US6+J22DRivdewYdyfyBe6orqZSj6Tw7l.aOjcwFy99uI MQlflmHfpCp4RWmpBc8vvzx1oXkH6zjOEpWh7e9Jgye8gx9JSM0SOhKgJgJk ArTqMd8ClU2BIv6fA5Cq3JuIe.oXmxZYbyUWPtrSW08XPJu19dA+oSMptKth onjz6mSk5kmxFLcEMU5x2dQfm8h.66Fitpy5jnDD8hZke40zIX1twqqCm7JS 2MlJZS29Z+UgW8KELCATHaORuKV.RjrBmdu.4dQz25W2HgQoufonuPSAVPyr RuK9BBqhltsm9gaFuoO3IjpfWWk1B81OcB0ykYfPRXlOenmVAmqzdRVFv5+R QmBRVImvjM.Yp48yGaJu58bPS+nt2qXy+bkthPycNP65yZamCzzuv3Ffsn4f ss2DnENmhss2jhsv4vZQ2DVKXNrV3qFZZApk+duJwsI -----------end_max5_patcher-----------
Obviously a Max audio effect.
Ok; this isn’t going to work. Been here before when I was working on my M4LScope (maxforlive.com link). I wanted that baby to be kinda bad ass too but eventually settled for one device per track because; as the patch shared above shows, you have a problem: latency. Or lag, or delays, or whatever you want to call it.
Sorry to disappoint but I don’t see this working. As you can see here; one patch, one channel. Left through live observer, right through direct audio in. Note the difference, see the lag, conclude what I came to conclude. Or proof me (and $OP) wrong; that’d be cool! (honest!)
Problem as I see it (though my conclusions can be off) is that the LOM doesn’t manage to grok the stuff MSP needs to handle. In all fairness; C74 turned audio handling (‘MSP’) into a separate module for a reason. But when using the LOM you’re basically using Max with the limitations it has (within the context of M4L).
I’m not 100% ‘on the mark’ at the time of writing but I don’t think this is going to work.
hey, thx for you fast reply. first off all, why do you say that my patch doesn´t match to what i explain? for me it does exactly the same like your patch. or did i get you wrong? the only different thing is that i used the sig~object because i thought i have to translate the digital signal to a audio signal. but your are right with your patch cause it shows the main problem a way easier than my patch.
anyway, this disappoints me quite a bit because the metering part/visual feedback is a important thing for my project. i understand your doubts referring to the limitations of m4l and if anyone have a workaround for this problem would be great.
but at the end of the day the big question is what can i do to build a device that match to what i need?
my next thought was to build something with external inputs. but if i get the audio limitations of m4l right a device can only have 2 audio channel?. my idea was to use soundflower and loop the audio signal back to a live device with the meters. but i want 4 meter with left/right, that need 8 inputs.
another idea is to use max/msp not max for live and build a external device. than connect the device via soundflower to ableton live. basically the same like in the idea above but without limitations of m4l. but i don´t want to buy max/msp only for this project, maybe if it´s the only way to realize my project but not in this stage.
the last idea was to use send~ and receive~ but i read a lot about latency with audio signals. so this might be not the best idea. my question is, is the latency the same if i use midi signals in order with the send~ and receive~ objects. because i could translate the audio signal to midi and than use the midi signal to drive the meter.
what do you think about my ideas?
thx for your help, i really appreciate this.
At a time, [send~] and [receive~] didn’t work in MFL. Is this not still the case ?
i´m not sure. i know that it works if you use it in one patch. but i have no idea if you can use it to transmit signals from one track in ableton live to another track. thats what i try to figure out at the moment. i had a look in the forum but couldn´t find anything yet.
send/receive is working pretty good and the latency for midi signals is quite low. so i think this would do the job to transmit the data.
Right, a little earlier on the evening and more sober than before, but not for too long ;-)
Yeah; my statement above that your patch wasn’t really showing the problem was a bit too hasty; I based my comment on seeing only audio connections and overlooked your use of the sig~ object, sorry for any confusion that may have caused.
Something with 8 inputs isn’t going to work too well because as you said yourself; Live is restricted to two audio channels per track. And indeed; send~, receive~ aren’t supported in M4L. That’s because M4L is using Live’s audio engine which doesn’t support routing in such particular ways. Another possible problem, though I can’t find any documentation on this, is that I recall such monitors to be very resource consuming. iow; if you try to monitor several channels at once using the live.observer that can eat away quite a bit of cpu.
So I think your idea to use an external device may be the better approach here. Can’t really comment on the how and such since all I ever experimented so far was rewire. Although this does give you more audio output channels it also imposes new limitations on Live (for example not being able to use vst’s nor M4L).
thx mate, thats what i supposed after my research. but like the phrase "there is always another way" i found a way which might be work. i want to use a midi signal to drive the meter. in fact of the the meter are supposed to show more the peaks then a exact volume the midi solution should be work. but i dont know how to translate the audio signal into a midi signal.
i discovered that you can use the send/receive object only for midi and not for audio signals in m4l. this give me the possibility to send the midi data to another device. the latency is quite ok. i tried it with some midi notes an it should be alright for metering. i started another topic for the audio to midi problem, may you can help me in this case as well.