Live API observe track output for metering _ need help please
hello,
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.
thank you
sebastian
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:
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?
1.
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.
2.
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.
3.
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.
edit:
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.
cheers
seb