This topic contains 15 replies, has 3 voices, and was last updated by 
-
Posts
-
something i don´t understand while using the osc device driver from sebastian.
i want to control a mastervolumefader of rme´s totalmixfx
did a short test with an application that is called oscmonitor (http://frieder-weiss.de/OSC/OSCMonitor.zip)
when i send an osc floating command, which is understood by totalmix, the values that are entered in v-control are not transfered one-to-one.
i.e. sending a /1/mastervolume 1.0 results in /1/mastervolume 0,50195 whereas sending a value 0.5 results in 0,50000…
sending 0.99 avoids the problem with 1.0why is it like this?
That is strange. I downloaded the software you’re linked and did not find any problems. (see screenshot of OSC monitor”)
I also included my project file. Please change the osc channel IP to your needs.
There is also a task in the script tab sending values from 0.0 t0 1.0 in 0.1 steps.
Can you please send your project file?
Attachments:
i´ll check this…
project file is attached…[attachment file=”Steuerung Kino bka.vc4.zip”]
I checked your project and for me it’s OK. I found only one issue. In the udp channel for OSC, there was no value for Router Hops. This value should be at least 1.
You are using Port 7001, the default port of the OSC monitor is 7000 for receiving (see my screenshot). Did you change the default port for receiving to 7001? if so, did you also change the Echo port to something else? Because the default for Echo is 7001. If not, this can result in a conflict.Anyhow, if I send 1.0 the OSC monitor receives 1.0
i tested it with your file, the same happens.
also i changed the script to count from 10 to 99 and the result is more than strange because several values are different.
i used 7001 in my project because totalmixfx has entered this port. i was also listening on port 7000 with oscmonitor…
the one thing that i forgot to mention is that v-control is running on your ubuntu image on a raspberry…
see the screenshots…[attachment file=1769]
Attachments:
the first 10 entries were done “by hand” sending a command from 1 to 0.1
OK, on Raspberry I can reproduce the issue. Maybe it’a a problem of Big / Little Endian on ARM and Intel CPU’s. It will take some time for me to check and fix this. Hopefully in the next release.
release date is on june 1st ? 😉
no problem.
i will send a few commands with delays to control the fader till thenthx dierk!
I found the bug and fixed it. But at the moment I don’t want to make a new release. To help you out I have updated the github repository. You find a compiled ARM32 version at
You have to replace all the files in the V-Control directory and sub directories with the files from github. After that make V-Control executable again. To do that open a file manager on the raspberry, navigate to the V-Control binary (V-Control4_Lin) and right click the file. Then select the tab permissions and select “allow execute”.
hi dierk,
i did as you described but v-control does not open
permissions are set
all files from github are downloaded and replaced
on the raspberry the icon for vcontrol does not change to an executable…can you open a terminal, and change to the V-Control directory
cd /path/to/V-Control
and then start V-Control by typing
./V-Control
Are there any error messages then?
oh sorry, it’s
./V-Control_Lin
yes. the error message says:
error while loading shared libraries: libunwind.so.8: cannot open shared object file: so such file or directoryThat supprises me because it should be in the image I provided. Anyhow, try
sudo apt-get install libunwind8-
This reply was modified 9 months, 3 weeks ago by
Dierk Walter.
You must be logged in to reply to this topic.