16 inputs is pretty heavy, with ps3eye cams you would need a stack of USB PCIe cards in a super powerful computer (depending on the machine you can get 1-3 per controller and this is not even normal SD video resolution). Just to unpack this many frames is a serious task, let alone doing anything with them. I have worked with multiple ps3eye cams and after 3 everything got flaky (I used 2 separate USB controllers). After that you will also have problems extending them (you have to use active extensions and the PS3eye is picky about this) and a very big power supply, they draw a lot of current I was using full speed USB hubs - full speed is hard to find in a USB hub- and 3 amp power supplies on the hubs, this lessened the power drain on the computer.
If this is a serious project and you have the time and money to make it work there are some other ways to achieve it. There is a 4 input blackmagic capture card (HDSDI --http://www.blackmagic-design.com/products/decklinkquad/), and you can use 4 HDSDI quad splitters --http://www.decimator.com/Products/MD_Quad/MD_Quad.html . You can capture full HD (if your machine has the guts) and break up each signal into 4\. I had to spec this out for a project that never got off the ground and it seemed like one of the simpler solutions, and the only method (4 inputs with 4 quad splits) that is really Isadora friendly and does not need other coding.
From here you can get almost Sd resolution from each camera. It is still resource heavy but this method will work- 16 usb cameras is going to be a hell of a fight.
Again, if it is serious then you can look into using industrial cameras like the fire mv. I have played a little with the SDK and a talented coder could write an input plugin for Isadora without too much hassle. You also get the option of dropping to monochrome on camera to reduce bandwidth use dramatically. There are a variety of machine vision cameras that are designed to be used in large numbers, they have on board memory and you can capture frames synchronously and download them asynchronously, allowing many more cameras on a single system. Again they dont come cheap but the images are great.
You can use the quad split method with cheaper hardware (there is a 4 input analogue card some people use, you will find it in the forum and you can use 4 quad splitters to get 16 low res analogue cameras into your machine.
If you dont need to see all of the cameras at once, try a matrix into the video inputs, you can find many with serial control so you can automate the camera swap. If you are not using cameras with reference in you will get a clunky change as each input re-synchronises.
How many cameras exactly do you want? Do you need them all active at the same time?
Thanks for taking the time.
That did the trick.
I have been watching your youtube tutorials, good stuff. In particular Value Scaling pt.1 & 2... it still has me baffled.
I am having a devil of a time trying to get a vertical line bar to "grow" with the (above) OSC vertical fader. It works, but the fader numbers are from 0-100 and the vertical are from 100-0.
I will make another post to keep things orderly.
To follow-up on Mark's post -- I was able to do some capture tests of 3 streams a few months ago with the same deck link quad card and had somewhat mixed results. With 3 streams I would see a significant number of dropped or duplicated frames, and/or bad artifacts.
I don't have the quad handy currently but I'd be happy to pass my test notes on to Mark in case recent changes in izzy may have helped out with the dropped frame issue.
I'm stuck on configuring the midi player to play on the stage.
I would like to have the midi player visible so it will be able to play midi files when someone "drags and drops" the midi file on the player.
Is that "do-able"?
Thanks for your time and advice.
Below is my graphic to help with understanding
Correct me if I'm mistaken, but isn't the point of Real Studio that it is its own development environment? Other than that, MAX/MSP/Jitter will produce standalones but they are not compiled applications so, while they will mostly behave like one, you wouldn't be able to import them into some other development environment for further development. This forum probably isn't going to be the best source of information on software development and we definitely can't give much in the way of useful suggestions without more information on what you are actually trying to achieve. Perhaps a good start would be to write several informative sentences that actually outline what your goals are with this project in lieu of a bunch of separate grammar-less sentence fragments.