.
Wow. Im all exited about the possibility to export my compositions as a Raspberry Pi app! Really hoping for this…
1 Like
Yes, please vote guys!
My problem is that I create live multimedia theater performances with live actors. My mobile MacBook Air has not enough power to drive a live performance, but I don’t have money for Mac Pro… So imagine: with this feature we could build compositions on Macs, export a linux app and run it on a very powerful linux machine, which you can build especially for running Vuo compositions, eg. on a show, performance. You can build cheap machine with very good graphics, many monitor outputs and so on.
Also, don’t keep your votes in a pocket! :)
Cheers, Teo
2 Likes
I didn’t have any more credits to vote on this feature yet but I’m really getting interested in the possibilities with this… especially since the Raspberry Pi 2 came out a few months ago!
1 Like
If this was implemented, how far would it be from a full-fledged Linux release code wise? I can imagine a lot of the framework has to be ported for this to work?
Magneson, the ability to deploy compositions to Linux would mainly involve changes to certain parts of Vuo: the compiler, the runtime, and OS-specific nodes.
The compiler/runtime is what allows compositions to actually execute on a computer. The compiler takes a composition (nodes, cables, etc.) and translates it into an executable for a specific CPU architecture. Currently, the compiler only supports one architecture, x86_64 (common to all recent Macs, and many Linux PCs as well). To be able to run a composition on a Raspberry Pi, the compiler would have to be modified to support additional architectures, ARMv6 and ARMv7.
The runtime handles some stuff common to all compositions. It’s largely independent of processor and operating system, but does have a Mac-specific implementation of the event loop. That would have to be ported to Linux.
Although we’ve tried whenever practical to make nodes OS-independent, some are specific to Mac and would have to be ported to Linux. This includes nodes involving windows, displays, GL contexts, images shared between processes, mouse, and keyboard.
So those are the main things that would have to be ported. The biggest things that would not be ported for this feature request are the editor and the build system.
The editor is based on a cross-platform GUI framework, Qt. Currently the editor contains a number of tweaks/workarounds for Mac-specific issues. Porting to Linux would probably mean adding some more tweaks/workarounds.
The build system is what we use to develop the code. In order to use Linux machines as developer workstations, we’d have to modify a number of scripts. It’s another case where we’re using cross-platform tools but OS-specific tweaks have to be made.
And finally, there are a few other scattered bits of Mac-specific code and documentation that would need to be ported.
So yeah, I would guess that this feature request would take Vuo more than halfway to a full-fledged Linux release, though substantial work would remain to be done.
1 Like
Thanks for the explanation Jaymie! I noticed early that using QT gave the possibility for Vuo to become cross-platform eventually, so any news in that direction is greatly appreciated (Vuo is a lot of the reason I’m still mostly on a mac).
Pretty interesting for the low cost Intel desktop option pointed to by Teo and the lightweight ARM turnkey device option with a sophisticated GUI (once Vuo gets GUI nodes). Could expand the Vuo user base indeed.
thanks for the explanation, Jaymie — very informative!
And ARM is moving fast: This little guy just got US$1.7 million dollars in backing on Kickstarter PINE A64, First $15 64-Bit Single Board Super Computer. repeat $15, deploy multiple projector and Artnet driver applications for example on multiple $15 devices.
Since this is currently the #1 top-voted feature request, I want to point out that it’s also one of the highest-development-time feature requests. We’d pretty much have to dedicate a release to it, and not implement any other top-voted feature requests in that release. When we (Vuo team) pick the feature requests that go into a release, votes are a very important factor, but we may pick a feature request with fewer votes over one with more if we believe it results in a combination of feature requests that has greater potential to expand the Vuo community, address the needs of the current community, and fit within a time frame of a few months.
Would it enable direct GPIO addressing or would that have to be a dedicated feature request? And how much extra money would you need to get it started?
GPIO nodes would be a separate feature request. Similar to Serial input/output, for using Arduino etc., they would enable a composition running on a Mac to communicate with a Raspberry Pi — whereas the current feature request is about making the composition run on the Raspberry Pi. Edit: GPIO nodes would enable a composition running on a Raspberry Pi to communicate with whatever’s connected to the GPIO port. It would require some extra effort on top of the current feature request. The implementation time would be 1-2 dots (maybe a week or two of work).
If Vuo gets ported to Raspberry Pi, would that mean the Pi camera modules would be available to the video input node or would that be another feature request? Would UVC webcams be supported on a Pi port?
@cwilms-loyalist, I’m not sure. We’d at least be adding some basic support for cameras under Linux (since the current camera nodes are Mac-specific). We’d have to do some research to find out how difficult it would be to add support for camera modules / UVC webcams beyond that.
I think basic support would be ok for a beginnig: bunch of input nodes (keyboard, audio, video), all of OpenGL/layers stuff, list nodes, math nodes and render nodes (to windows, screens (Xserver) and images). Maybe it’s a good idea to make some poll which categories of nodes are most important for users?
2 Likes
As a self identifying Apple Fanboi, this is a really hard post for me to write. Considering Apples current trajectory: soldered ssd, non existent pcie slots, this feature request may be nessesary for the future of Vuo.
I am interested in using Vuo for multiprojector setups, huge data walls, 360 etc, and currently- no matter how fantastic MacOS is, ( we all know how great and stable macos is) Apples hardware lock-in is becoming the most limiting factor.
It is impossible for me to set up a system for clients without crazy work arounds, (using old macpros which have pci slots etc ).
I believe strongly that Vuo will gain a whole new user base once it is Cross platform, and have a super exciting future!
I for one will vote for this as the number 1 priority for the next release cycle (post 1.3)
@jstrecker, would it be possible to split this request into two?
I would like to see Vuo on Linux desktop first, as this would give us quick access to extremely powerful playback solutions. Would that at least make this request a bit simpler to achieve in one release cycle?
RPi could follow after Linux is stable?
1 Like
I am interested in a Linux version as well. However since much of my interest in Linux relates directly to the RPi I would actually be pretty disappointed if it wasn’t supported right at the beginning.
@alexmitchellmus, as @cwilms-loyalist points out, the problem would be how do you do so in a way that is fair and transparent to the people who voted on the FR with the understanding that it would support Raspberry Pi.
This is important to the future of Vuo I would think. Not so much use to me for now, but expanding the commercial base of Vuo is critical to keep it developing the way we want it to.
Love the idea of cheap Linux ‘rackmounts’ driving installations and live performance at more reasonable cost and the idea of deployable RPi scientific and health devices for logging and processing real time physical world data. (And any kinds of sophisticated automation that can drive interesting graphical output/UI/UXs)
Air quality monitoring around industrial sites and fossil fuel extraction points with a simple user UI they can see on cheap touch screens. That’s fancy UI stuff is all very hard to wrangle with Arduino/RPi today. Some kind of code bridge or binding to the hard core data aquistion and processing programs would be neat way to close this loop.
1 Like