search

jamoma / JamomaCore

Jamoma Frameworks for Audio and Control Structure
Other
37 stars 14 forks source link

Jamoma / Minuit doesn't update internal state when receiving OSC value from distant App. #387

Closed avilleret closed 9 years ago

avilleret commented 9 years ago

hi,

I'm playing around with DemoApp and want to send data value to Max patch. I made a Max patch that connect to DemoApp and with which I can update /myParameterDecimal, but I can't find an easy way to send back data from DemoApp to Max.

When I type in the console prompt : 

/myParameterDecimal 0.1234

On the Max side, j.modular monitor shows that it receive the data, but [j.remote myDemoApp:/myDecimalParameter] doesn't update its value.

While when I type : 

myDemoApp:listen /myParameterDecimal 0.1234

On the Max side, j.modular monitor shows the data and [j.remote myDemoApp:/myDecimalParameter] update its value.

After reading the Minuit spec, it seems to me that sending OS data (like in my first try) should update the value. So I'm guessing why I have to write such complicated string to make it work.

Did I miss something or is there a JamomaMax issue ? Any hint is welcome.

theod commented 9 years ago

is possible you have launched the Max patcher before the DemoApp ? in that case the [j.remote] could have tried to listen to parameter change while the DemoApp wasn't here ? that could explain why you have to enable the listening your self.

avilleret commented 9 years ago

Launching order doesn't seem to matter, I have the same result when launching Max after DemoApp or vice versa.

When does [j.remote] 'listen' to a parameter ? I though that as soon as Jamoma is aware of a modification, it notifies each listener (and thus j.remote). So I'm wondering why sending /myParameterDecimal 0.1234 doesn't update Jamoma state ?

theod commented 9 years ago

so it sounds like a bug ...

avilleret commented 9 years ago

ok, but is it a JamomaMax bug or JamomaCore one ? for now I'm leaving this issue open but it sounds relevant to open a new one with a more precise title and description asap

theod commented 9 years ago

I'll work on this this morning. you just change the title instead of creating a new issue.

theod commented 9 years ago

a one question relative to DemoApp : should the DemoApp folder be configured by Cmake or not ? here it is not and I'm not sure of what to do to make the project alive. how do you do it on your side ? I tried to make an Xcode project from scratch but I encounter troubles when launching the app due to @rpath stuff ...

avilleret commented 9 years ago

a new but undocumented option enable it at configuration step : 

cmake -DJAMOMA_MODULAR_BUILD_DEMOAPP:Bool=True ..

it should appear in cmake gui

theod commented 9 years ago

nice !

theod commented 9 years ago

ok I've managed to build and install the DemoApp using Cmake system but when I launch it is still crashing due to the same problem when loading dylib :

dyld: Library not loaded: @rpath/libJamomaModular.6.dylib Referenced from: /Users/WALL-E/Documents/Developpements/_Build/Jamoma/DemoApp/DemoApp Reason: image not found

where do you install your DemoApp to launch it properly ? or what could I've missed during the process ?

avilleret commented 9 years ago

I though that @laugre fix this issue (related to #https://github.com/jamoma/JamomaCore/issues/385) But you may have to install the JamomaCore package by trigging install target, either with make install, ninja install or selecting install target in Xcode. You may need to run them with sudo.

On linux, I use LD_LIBRARY_PATH to add Jamoma extension folder to system lib search path. This can be use when installing in a sandbox instead of in the system root (to do so configure the CMAKE_INSTALL_PREFIX at cmake step). On Mac OS X, you can try DYLD_LIBRARY_PATH=/path/to/extension/folder ./DemoApp

theod commented 9 years ago

ok fine ! setting DYLD_LIBRARY_PATH environment variable to /usr/local/jamoma/lib resolved the trouble.

avilleret commented 9 years ago

yep this path is hardcoded to a strange value see https://github.com/jamoma/JamomaCore/commit/7885bc4385613b280f9485d2f59d7815a4234924 and ping @laugre ;-)

theod commented 9 years ago

ok I found the trouble. it is just the way DemoApp works ! actually the Execute function only speak to the remote application so it's sending /myParameterDecimal to the remote app instead of sending this the DemoApp (where the parameter is) and so the remoteApp doesn't understand the message as it does't have such a parameter (just a remote). this is also explaining why when you send myDemoApp:listen /myParameterDecimal 0.1234 it works as you simulate the update of the parameter.

so I change the Execute method in order to speak to the local application instead of the remote.

theod commented 9 years ago

for the record the problem with DemoApp is maybe due to those errors during install step :

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: for architecture x86_64 object: /Users/WALL-E/Documents/Developpements/_Build/Jamoma/DemoApp/DemoApp malformed object (inconsistent sizeofcmds field in mach header) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: for architecture x86_64 object: /Users/WALL-E/Documents/Developpements/_Build/Jamoma/DemoApp/DemoApp malformed object (inconsistent sizeofcmds field in mach header) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: for architecture x86_64 object: /Users/WALL-E/Documents/Developpements/_Build/Jamoma/DemoApp/DemoApp malformed object (inconsistent sizeofcmds field in mach header)