Lemur sending OSC from monitoring

[Eric]

hi everyone,

i'm a newbie in lemur, sorry if that question sounds stupid, or has been asked previously.
I have some issues with re sending osc from lemur control (any). Let's take a simple slider for instance. This slider controls a Daw (live, cubase, whatever). I record an automation in the daw with that slider. Now by playing back this automation, the slider is moving by itself. I ask it to re send value in osc in the same time to another device (max, reaktor whatever). I do configure everything well, from the command in this slider to the device adress, osc, everything. But thing is, the slider doesn't send anything back when it is moving according automation. It does send data when i am moving myself from lemur, but doesn't send the feedback datas in automation. I assume it is a kind of monitoring issue, a midi to osc trick , and i hope there's a way to go around that.

Any solution?
thx!

[Softcore]

Here's the thing.... In order to avoid a constant "loop" between a mapped parameter and a Lemur object, WHEN a Lemur object is moved by received data (feedback from Daw) it doesnt send that data back out....if it did, you would experience weird jittering movement of both the DAW and the fader, the one trying to catchup with the other - I know this for a fact because I have witnessed it too many times in some of my poorly designed custom midi feedback scripts lol.

What you CAN DO though is use a scripted OSC output that will take the moving (by feedback) fader x value and then send it your desired OSC target. If you are not feeling comfortable with oscout script function and you just want one fader to do this kind of functionality a really "nasty" un-scientific way would be to create a second dummy fader, set it via script to follow your first fader (dummyfader.x = realfader.x) and then map THAT dummy fader to your desired OSC target.

P.S. you MIGHT be able to get away with using an added custom expression in your fader, set it to follow x and then map THAT expression to your desired OSC target. Try this.....Add a new custom expression in your fader ( button x= in desktop editor). Lets name it K and then set it so that K = x
Now use the standard mapping settings but instead of mapping x to your desired osc target map K.

[Eric]

thanks for the help!

i understand what you are saying, and will definitely try your solution . But in the same time, i don't see what could make feedback data loop, if that fader, for instance, could resent osc data but to another device/address (the other device won't resent). Actually, it is what i ve tried. The fader while sending midi does send osc to the other device, but only if you touch or move it by yourself. But that doesn't work, if the fader is automated by the daw. To me theoretically, there are no supposed reason to create loop, if that lemur object receives a midi data, and resent osc data to another device in. It does work in a way : a device send osc to a lemur fader, and this one sends midi to a specific daw. So if that works in that way, why not in the other? I understand that lemur only accept to do it if it is the one that generates midi from osc. It doesn't want to translate midi to osc in the other side, but that a point that could be improved, no??

That would make lemur to be like an osc hub in order dispatch data. That could be precious, especially because a lot of daw only accept midi (live, nuendo cubase, logic etc).

[Softcore]

Yeah but IF that mapped fader WAS sending data out when receiving it, it would also send it out to the already mapped parameter get it?

Picture this.....Lemur fader is mapped via midi with DAW fader 1. You want it to receive data from DAW fader 1 and resend them as OSC....Then it would also "have" to resend the midi data.....So while the DAW Fader 1 is sending feedback to Lemur Fader, the Lemur fader is sending its (quite a bit "behind") data (previously recieved as 'feedback") BACK to the DAW Fader.

Gee I suck at explaining but give it some hard thought and you'll see what I mean!

I also dont think it even works the other way as you describe - have you checked that if a Fader is moved by OSC feedback, it indeed sends out midi data? I havent, as I usually work with midi and not OSC. I think though, it only sends data when there is user-interaction involved (or physics engine of course) but I might be mistaken.

Of course, what you are asking is not resending the midi data as midi but resend the midi data as OSC and I understand that this wouldnt create a feedback loop...and then one other would want the oposite, resend the OSC data as midi....and then a third user would say "hey, why not Lemur is smart enough to see that the incoming data and the outgoing data are not targeted to the same port-device therefore no feedback-loop is going to happen therefore allow the operation?" to which I would reply, "Dont ask me, I didnt develop the damn thing" ....lol

So all Im saying is that curently to avoid such situations, it has become clear to me that Lemur works in such a way that received data feedback is not resent out of the same object regardless of the type of message being received as opposed to the one being demanded. The discrimination is not there!

[Softcore]

Actually it occured to me late last night, that my replies to your questions couldnt be more wrong as far as how Lemur works. I dont know how I got confused (well I do but thats another story, I mixed up Lemur features with my own DAW features), but the important fact that I have to correct (mentioned in my replies) is that I was wrong saying Lemur wont be sending data if that data was received as feedback. In fact, I really dont have a clue why it doesnt send OSC data with the way you described.

I knwo Im getting you back to square one, but I had to correct my inaccuracies.

[Eric]

yeah i don't understand either, especially because, it works when you move the fader youself.. but doesn't work when the fader is automated from the daw.

damn!

[Macciza]

Hi
I have checked this out a bit behind the scenes - there was some unexpected results being seen in certain situations . . ..

In general the rule has been that the mapping options are only for touch response and feedback reception - not pass thru which would need to be scripted.
I believe they may be looking into whether some easy system of OSC<=>MIDI bridging can be achieved as it seems it may be possible, will have to wait and see on that . . .

The only solution would be to write scripts that take the incoming MIDI and send out OSC as needed . . .

Cheers
MM

[Eric]

catching up this old topic. I am stuck with the same problem, and the same point.

I have a fader that is controlled by external software :
- sometimes it is automatized and move by itself according other softaware osc input -
- sometimes i take manually the control of this same fader by turning off the other software.

In the first case, when moving by itself, the fader doesn't send osc out (to another control). In the second case, of course, it does send osc.

I want to have the fader to send osc even in automatized mode!

could someone have a solution to this?

thx!

[Macciza]

Hi
Maybe just post what you have for your fader and we can tweak that for you
Will have a quick look when possible
Cheers

[Macciza]

Hi
Sorry for the delay in getting back to you . .
Particularly with such a surprisingly simple solution, though other equally simple solutions gave mixed results...

Any make a script inside an object executing on x, as the value you wish to track.

outx() - oscout(0,'/test/x',x);

This should work to send that message whether from internal or external control, you can disable the normal x value.

Alternately you can just ad a var/expression - 'outx = x'. And set values there . This works to change address but goes a bit weird when set to the same address as input in certain cases,. Will have to get back to you on this..
Cheers