Live android controllable mix desk

[winger]

I have a remote interface I am working on. I have it working and have used it several times now for live performance. I use 3 behringer bcf2000 to control 16 channels, 7 aux masters and main. A shift button changes 1-16 to be 17-32. A bcr2000 is used to control all channel functions (4 band para-eq and compression) Basically I have a 24/48 mixer but it is 32 channels (no stereo channels). I did this using a bunch of separate modules I created. It also uses a windows C++ application to handle midi mapping, saving patches, fader grouping, etc. Works great. http://forums.planetz.com/posting.php?mode=post&f=11#

Then I added a web server to the computer extended the c++-program so I communicate using html, php and c++ so now I can control all functions wirelessly with a web enabled device. I am currently using an 10" asus transformer(android) for this. It is really cool.

I have a couple of things left I would like to do on android: vu meters, eq graphs and compressor graphs.

I was hoping I could create a device that would take the output from a view meter mdl and convert it to midi data of some kind and send it to may C++ ap for display on the android. Any ideas about how to do this or if it is even possible?

The graphs should be easy, all I need is find out the math to generate the graph from the midi parameters used to control the filters. If I could see code for the eq displays that scope uses it would probably trivial. Anyone know anything about this?

[astroman]

funny thing: I didn't read your post properly and immediately came up with the same midi idea.
eg dedicate a channel to meters and send the stuff as CC giving a resolution of 127 (and even expecting some 'receivers' might already exist on Android)
but then... considering update rates that's likely a flood of controllers... barely usable if at all

first things first, though
the drawing is probably not where it's at, that would be the handling of hold/decay behaviour of the meters.
You need some strategy in advance for this, then package the values and send them off...

I guess a table structure (with channels as columns)might be a good base
allows you to handle 1 to n meters with the same routine and provides some space for specific treatment of certain ranges
(intermediate storage, logical or value comparisons, if any...)
values are filled in constantly according a time grid
after a decay specific offset isolated peaks are simply reset
may depend a bit on the graphic layout, but could get along without any comparisons
...well, that might be a bit optimistic... let's say 'few'

Imho you can do this in any highlevel/script language, compiled code doesn't give much advantage in your environment.
The majority of resources go to the network stuff, which you probably don't want to redo on your own...

cheers, Tom

[winger]

Right now I am trying to figure out how to make the scope device that would send the vu data via midi. I would want the device to send midi data periodically, not continuously. An update date rate of 100ms or longer I would think. However, I don't know how to do this. If I use a vu device I can get a value. How do I sample every 100 ms and convert the data into midi to be sent? It could be a midi controller or ever note on/off velocities where the note is the channel number. If I can't get the data out via midi, trying to figure out the rest is just a waste of time.

[tgstgs]

i have never seen a device posted from you_
so please let me ask:
_is this a commerzial project supporting SC
_is this a free project supporting SC customers
_or is this for something else

?? vibes

[winger]

i have never seen a device posted from you_ I have not posted any devices as of yet
so please let me ask:
_is this a commerzial project supporting SC non-commercial, for my own use
_is this a free project supporting SC customers Yes, I will eventually post the devices. Right now most of the devices are probably not something others would want. They are designed to work together in a project to get around the limitations scope has with midi. I have been thinking about doing a video to demonstrate what I have and then if anyone has any interest in the devices I will share them.
_or is this for something else

?? vibes

Currently the drawbacks of my setup is that the project itself is very complex and the C++ program that does the midi mapping is very specific to my project. If I were to figure out a way to simplify the project so others might want to try the same type of thing, I would consider re-writing the C++ part in a way to make it so end users can configure the midi the way they want. I have been kind of hacking away at this off and on for about 3 years.

If there are others interested in this project, I will start some threads to discuss where the hard parts are and maybe we can come up with ways to simplify it so it would be useful for others.

[tgstgs]

i love creativity and i like people with a long breath_

could well be developers know more to do with it than . .

so2all:

// feel free to use for free
// for comerzial use please contact SC or me
//
// you need win x86
//
//////////////////////////
// Send switches the algo on/Off
// NN is the NoteNUmber you want to send
// Peak is tested with the peak output from a stock VUmeter
// adjust the responsetime with the peakholdtime for example
// Mout is the midioutput
//////////////////////////

would be nice to drop me a line when you use it-> whereever whatever whoever

good vibes

[winger]

Ok, I loaded it up and it seems to work. I assume NN is note number. It sends a midi note on velocity representing the vu level, right? What does signal coming in on the peak do?

[tgstgs]

asyncIN Peak scales 0-2147483647 to 0-127 Midivelocity_

just test it im sure you makes use of it_

good vibes from vienna

[dawman]

Anything MIDI and Scope is of interest to me.
Please continue by all means...

Vibes from Vegas....
Ankyu

[jksuperstar]

I've been trying to work a touch screen into the mix...to avoid any MIDI programming, channels getting flooded with data, and all those things. Maybe something running on the same host PC, so i can have both SCOPE elements and a touch interface I love having a meter involved always, so I've got a setup with a 23" screen, not touch yet, but with a BCR and a BCF right in front of it. A smaller screen would do just fine, especially with higher resolution to handle a full 2448 mixer displayed, plus meter, plus some third party touch application. OSC is perfect for that kind of thing, since bandwidth is dependent on ethernet. If you use a remote device, I'd recommend using wired ethernet, gigabit if possible. That avoids all the overhead involved with wireless uni-directional comms, and all the error correction and packet re-transmission, too.

[winger]

I finally got around to working on this again. It works to a point. I am using a vu meter mdl to convert the audio data to the async signal. I send the peak out to the peak in and level out to the input of your device to get midi data. This works but the levels end up being not very useful. At +12db I get a velocity of 127, +6db about 60, 0db about 30, -6db about 15, -12db about 7. This makes sense. However, it would be much better if I could get the velocities to be reverse logarithic so the midi velocity value is linear to the graph.

The vu meters on my DM-24 go to +10 to -60 followed by infintity, with -15 being about mid scale. Is there a way to scale the data out of the async converter so the midi data is logarithmic? Maybe the vu meter output can be scaled before feeding it the sync. I don't know how to do this. I would guess it can be done with one of the atoms but the names don't explain what the atoms do very well. Any ideas?

[winger]

Correction, -25db is mid scale.

[winger]

My eyes are going bad. I was right the first time, -15 is mid scale. The master fader starts at 0, and -25 is mid scale, where as the channel faders start at +10 with -15 at mid scale. So ignore my last post.

[tgstgs]

to modify controler data i would search for a controler modifier;
could well be there is a folder called modifier too;

who knows vibes

[winger]

Sorry I took so long for a follow up(if anyone is interested in what I am doing). I got the meters to work using your device. Response is a little slow(not due to the midi vu device) but usable.

However, this created a problem for me. The data coming to the browser for vu data, interferes with the mix functions. For example if I move a fader or push a button while vu data is going out, the button press for me change may get missed. I realized this is due to the fact that my protocol for sending data back and forth is request reply, and if 2 happen at once I can get the reply for the wrong one, confusing this. Since I don;t know how to implement a mutex in a web page I will need to modify my protocol. I know how to do it but I won't have time to do it for a while.