Hi there, list!
Besides using PD for sound design and programming/composition tools, I've always thought it could be a great platform for "show control", replacing commercial apps like Qlab and others. For those of you who are not familiar with this sort of tools, they are built to streamline the process of "cueing" a performance (theater is my main focus). Cues can be playing, pausing, fading in or out given audio files (and panning, filtering, etc), sending out DMX or MIDI signal for light consoles, as well as playing, pausing, fading in or out given video files. Live video and audio are also possibilities. Each function is apparently simple to implement and I've used some experimental patches in shows of my own, but I've met some resistance from "conventional" technicians. Some testing with Qlab, has led me to the conclusion that a Pd solution could be built and useful, but it would need a simpler GUI for the final control aspects, to resemble as close as possible existing paradigms (some sort of hybrid between an audio mixing board and the normal controls on a CD/audio player, the cueing principles of lighting systems and existing video mixing consoles). A modular system would be perfect for this, and I'm trying to figure out how to start. With such a broad community of users, I'm sure some attempts at this have already been made and I'm not interested in reinventing the wheel. So, if any of you can point me to existing projects with similar features and objectives I'd appreciate it and try to contribute as best as I can.
Thank you all,
João Martins
Hello,
on my side, I'm using Pd in almost each show or installation I made. I use it as a media server (audio and video player and synthesizer, light and actuator control). The cue control is still a big point. But I think I have now with I-score [1] something really efficient. This is an intermedia sequencer working with MIDI, Minuit and OSC. It's a great tool to do show control. It doesn't play media itself but send command to other programs (like pd). You can easily write automation by hand, or record them with controller. It implement a lots of very nice feature like global speed control and cue triggering condition. It's still in beta but the dev' crew is very reactive to fix bug and implement new features. It's open source and run on Mac OS, Linux and Windows (binaries are available).
This is the most powerful software I knew to do show control. (but Ok, I know the team, and I'm quite involve in its development :-) ) Feel free to try it and reach the team if you have any question.
Cheers
Antoine
do it yourself http://antoine.villeret.free.fr
2014-11-13 11:10 GMT+01:00 João Martins joaomartins@mac.com:
Hi there, list!
Besides using PD for sound design and programming/composition tools, I've always thought it could be a great platform for "show control", replacing commercial apps like Qlab and others. For those of you who are not familiar with this sort of tools, they are built to streamline the process of "cueing" a performance (theater is my main focus). Cues can be playing, pausing, fading in or out given audio files (and panning, filtering, etc), sending out DMX or MIDI signal for light consoles, as well as playing, pausing, fading in or out given video files. Live video and audio are also possibilities. Each function is apparently simple to implement and I've used some experimental patches in shows of my own, but I've met some resistance from "conventional" technicians. Some testing with Qlab, has led me to the conclusion that a Pd solution could be built and useful, but it would need a simpler GUI for the final control aspects, to resemble as close as possible existing paradigms (some sort of hybrid between an audio mixing board and the normal controls on a CD/audio player, the cueing principles of lighting systems and existing video mixing consoles). A modular system would be perfect for this, and I'm trying to figure out how to start. With such a broad community of users, I'm sure some attempts at this have already been made and I'm not interested in reinventing the wheel. So, if any of you can point me to existing projects with similar features and objectives I'd appreciate it and try to contribute as best as I can.
Thank you all,
João Martins
-- João Pedro Martins música . web design http://joaomartins.entropiadesign.org mail: joaomartins@mac.com skype: joaopsmartins ichat: joaomartins msn: joaopsmartins
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 13/11/14 21:10, João Martins wrote:
Each function is apparently simple to implement and I've used some experimental patches in shows of my own, but I've met some resistance from "conventional" technicians. Some testing with Qlab, has led me to the conclusion that a Pd solution could be built and useful, but it would need a simpler GUI for the final control aspects, to resemble as close as possible existing paradigms (some sort of hybrid between an audio mixing board and the normal controls on a CD/audio player, the cueing principles of lighting systems and existing video mixing consoles). A modular system would be perfect for this, and I'm trying to figure out how to start.
I have run many installations and shows with pd ... its strength is also its weakness for this. Pd is a language, it isn't a modular GUI system. That means you do pretty much whatever you can find the time and programming skills to make, test etc. You are freed from the constraints of the current set of interface paradigms. You are on your own. It means you need to make any elegant or conventional-style interface you want to present to an operator, and it means that operator must be happy using a custom, hence unfamiliar, interface (often labelled "un-intuitive" because it isn't an exact copy of the tools they know well).
All this takes time and effort to get right, if you are simply looking for the cheapest way to plot and operate a show (including costing some of that time) then buy whatever tool your operators already know, and spend your time setting that up well. But that imposes quite restrictive workflows, it limits what you can do (but in familiar ways that people accustomed to working that way will readily accept).
Use pd when you will operate the show yourself, use pd when it is behind a physical faders and knobs surface, use pd when you really have the time to make, test, learn and teach a custom interface and are working with people willing to embrace that, use pd for creating all kinds of responsive or semi-autonomous systems, use pd when you want to set up particular sequences and scenes yourself and can simply expose a series of GO buttons plus maybe a volume control or such for an operator to use.
Certainly build up your library of parts/modules for this, and borrow from the many published collections of such! But it is a lot of work to polish an interface to plot and run a show, and to make it bulletproof ... especially in the hands of a nervous operator in front of an eager audience ... that is what you are paying for when you buy a cueing system (and some of them do provide just that). It can be a very good learning process to re-invent the wheel, if that is your goal, and very satisfying to DIY if your have the time and patience.
Simon
Hi there, list!
Besides using PD for sound design and programming/composition tools, I've always thought it could be a great platform for "show control", replacing commercial apps like Qlab and others. For those of you who are not familiar with this sort of tools, they are built to streamline the process of "cueing" a performance (theater is my main focus). Cues can be playing, pausing, fading in or out given audio files (and panning, filtering, etc), sending out DMX or MIDI signal for light consoles, as well as playing, pausing, fading in or out given video files. Live video and audio are also possibilities. Each function is apparently simple to implement and I've used some experimental patches in shows of my own, but I've met some resistance from "conventional" technicians. Some testing with Qlab, has led me to the conclusion that a Pd solution could be built and useful, but it would need a simpler GUI for the final control aspects, to resemble as close as possible existing paradigms (some sort of hybrid between an audio mixing board and the normal controls on a CD/audio player, the cueing principles of lighting systems and existing video mixing consoles). A modular system would be perfect for this, and I'm trying to figure out how to start. With such a broad community of users, I'm sure some attempts at this have already been made and I'm not interested in reinventing the wheel. So, if any of you can point me to existing projects with similar features and objectives I'd appreciate it and try to contribute as best as I can.
Jörn created something perhaps related a while ago. Not sure about its current status as well: http://www.spinics.net/lists/linux-audio-users/msg84742.html
best, P
On 11/13/2014 11:10 AM, João Martins wrote:
Thank you all,
you might checkout marian weger's "kollabs" library. it's Pd-vanilla only, and quite powerful.
github: https://github.com/m---w/kollabs documentation: http://iem.kug.ac.at/projects/workspace/2014/kollabs-ds-a-state-saving-syste...
the above doc-link to the iem-homepage sucks for length's sake (and might get broken by your MUA), so here's a shortened version: http://bit.ly/1GTsyRe
gfmsadr IOhannes
Thank you all. I-score seems very promising and I'll look into it and the kollabs/ds library.
Peter nailed the issue spot on. All that Pd allows me to do has made my work and my thought processes evolve and that's amazing. In the "real world", however, I rely on technicians who do not use it and I always have to find ways to make friendlier interfaces. Most of the times, I end up operating things myself and that's absurd: theatre plays where I'm stuck for the entire run, with the venue's sound tech by my side, not doing it because it's not the "play/pause, fade in/out, cross fade on a mixer's knobs and faders, kind of thing"… Of course I can go the commercial way and use Qlab. The thing is: if I can get technicians to work with Qlab (I did that, already), could I build something myself? I-score and kollabs/ds, attached to an external controller (there are cheap MIDI / DJ options who are just like the "regular stuff"), could do the trick. I'll keep searching for that balance between flexible and customized performance control and ease of use for "others". And yes, I'm aware of the dangers of trying to reinvent the wheel.
All the best,
João Martins
No dia quinta-feira, 13 de Novembro de 2014, IOhannes m zmölnig < zmoelnig@iem.at> escreveu:
On 11/13/2014 11:10 AM, João Martins wrote:
Thank you all,
you might checkout marian weger's "kollabs" library. it's Pd-vanilla only, and quite powerful.
github: https://github.com/m---w/kollabs documentation:
http://iem.kug.ac.at/projects/workspace/2014/kollabs-ds-a-state-saving-syste...
the above doc-link to the iem-homepage sucks for length's sake (and might get broken by your MUA), so here's a shortened version: http://bit.ly/1GTsyRe
gfmsadr IOhannes
On 11/15/2014 08:37 PM, João Martins wrote:
Thank you all. I-score seems very promising and I'll look into it and the kollabs/ds library.
Peter nailed the issue spot on. All that Pd allows me to do has made my work and my thought processes evolve and that's amazing. In the "real world", however, I rely on technicians who do not use it and I always have to find ways to make friendlier interfaces. Most of the times, I end up operating things myself and that's absurd: theatre plays where I'm stuck for the entire run, with the venue's sound tech by my side, not doing it because it's not the "play/pause, fade in/out, cross fade on a mixer's knobs and faders, kind of thing"… Of course I can go the commercial way and use Qlab. The thing is: if I can get technicians to work with Qlab (I did that, already), could I build something myself? I-score and kollabs/ds, attached to an external controller (there are cheap MIDI / DJ options who are just like the "regular stuff"), could do the trick. I'll keep searching for that balance between flexible and customized performance control and ease of use for "others". And yes, I'm aware of the dangers of trying to reinvent the wheel.
All the best,
João Martins
For a few shows that needed the more advanced audio handling capabilities of Pd, I used this: http://stackingdwarves.net/public_stuff/software/CueFrog/CueFrog-0.0.4-Scree...
Basically, just a bit of bling around readanysf~. But Pd's abysmal string handling capabilities have been the major roadblock that prevented me from developing it further. I still like to use Pd for shows I'm running myself, but those I hand off, I gladly rely on QLAB and sleep soundly at night :) (just premiered another one where I was forced to use the latest QLAB on the latest mac os version that got released only a few days before, was scared out of my wits but got lucky :)
Le 13/11/2014 11:10, João Martins a écrit :
Hi there, list!
Besides using PD for sound design and programming/composition tools, I've always thought it could be a great platform for "show control", replacing commercial apps like Qlab and others. For those of you who are not familiar with this sort of tools, they are built to streamline the process of "cueing" a performance (theater is my main focus). Cues can be playing, pausing, fading in or out given audio files (and panning, filtering, etc), sending out DMX or MIDI signal for light consoles, as well as playing, pausing, fading in or out given video files. Live video and audio are also possibilities. Each function is apparently simple to implement and I've used some experimental patches in shows of my own, but I've met some resistance from "conventional" technicians. Some testing with Qlab, has led me to the conclusion that a Pd solution could be built and useful, but it would need a simpler GUI for the final control aspects, to resemble as close as possible existing paradigms (some sort of hybrid between an audio mixing board and the normal controls on a CD/audio player, the cueing principles of lighting systems and existing video mixing consoles). A modular system would be perfect for this, and I'm trying to figure out how to start. With such a broad community of users, I'm sure some attempts at this have already been made and I'm not interested in reinventing the wheel. So, if any of you can point me to existing projects with similar features and objectives I'd appreciate it and try to contribute as best as I can.
you can have a look at my "linear cue system"
http://www.chnry.net/ch/?094-Linear-cue-system&lang=en
nothing special, but it fit my needs.
cheers c
Thank you all,
João Martins
-- João Pedro Martins música . web design http://joaomartins.entropiadesign.org mail: joaomartins@mac.com mailto:joaomartins@mac.com skype: joaopsmartins ichat: joaomartins msn: joaopsmartins
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello everyone, I am very interested in show control, and I have been dreaming about developing a complete set of open source show control software since years.
I think that Pd could be part of a backend, but it lacks some features of a sturdy "real" programming language. Namely: a unit testing framework, multi-threading, etc.
I think that the ideal GUI for a show control application should be Web-based. It would allow it to be distributed. I have already done such distributed Web GUI applications in the past. I am very satisfied with it!
I am not sure how we could find some money to develop such a set of tools, but please let me know if anyone is interested in thinking about this seriously. Let's start a mailing list and get our brain thinking and our hands writing code!
Best,
2014-11-16 8:24 GMT-05:00 Cyrille Henry ch@chnry.net:
Le 13/11/2014 11:10, João Martins a écrit :
Hi there, list!
Besides using PD for sound design and programming/composition tools, I've always thought it could be a great platform for "show control", replacing commercial apps like Qlab and others. For those of you who are not familiar with this sort of tools, they are built to streamline the process of "cueing" a performance (theater is my main focus). Cues can be playing, pausing, fading in or out given audio files (and panning, filtering, etc), sending out DMX or MIDI signal for light consoles, as well as playing, pausing, fading in or out given video files. Live video and audio are also possibilities. Each function is apparently simple to implement and I've used some experimental patches in shows of my own, but I've met some resistance from "conventional" technicians. Some testing with Qlab, has led me to the conclusion that a Pd solution could be built and useful, but it would need a simpler GUI for the final control aspects, to resemble as close as possible existing paradigms (some sort of hybrid between an audio mixing board and the normal controls on a CD/audio player, the cueing principles of lighting systems and existing video mixing consoles). A modular system would be perfect for this, and I'm trying to figure out how to start. With such a broad community of users, I'm sure some attempts at this have already been made and I'm not interested in reinventing the wheel. So, if any of you can point me to existing projects with similar features and objectives I'd appreciate it and try to contribute as best as I can.
you can have a look at my "linear cue system"
http://www.chnry.net/ch/?094-Linear-cue-system&lang=en
nothing special, but it fit my needs.
cheers c
Thank you all,
João Martins
-- João Pedro Martins música . web design http://joaomartins.entropiadesign.org mail: joaomartins@mac.com mailto:joaomartins@mac.com skype: joaopsmartins ichat: joaomartins msn: joaopsmartins
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I would love to see this idea expanded or developed. The issue i have run into over and over again is that pd would need to be CUED from patch to patch so one could design a linear show. I have not seen this possible the way it's designed. For this reason i use Isadora, http://troikatronix.com/http://troikatronix.com/
Patrick Pagano B.S, M.F.A Audio and Projection Design Faculty Digital Worlds Institute University of Florida, USA (352)294-2020 ________________________________ From: Pd-list [pd-list-bounces@mail.iem.at] on behalf of Alexandre Quessy [alexandre@quessy.net] Sent: Sunday, November 16, 2014 12:06 PM To: Cyrille Henry Cc: pd-list@mail.iem.at Subject: Re: [PD] Approaches to "show control" platforms
Hello everyone, I am very interested in show control, and I have been dreaming about developing a complete set of open source show control software since years.
I think that Pd could be part of a backend, but it lacks some features of a sturdy "real" programming language. Namely: a unit testing framework, multi-threading, etc.
I think that the ideal GUI for a show control application should be Web-based. It would allow it to be distributed. I have already done such distributed Web GUI applications in the past. I am very satisfied with it!
I am not sure how we could find some money to develop such a set of tools, but please let me know if anyone is interested in thinking about this seriously. Let's start a mailing list and get our brain thinking and our hands writing code!
Best,
2014-11-16 8:24 GMT-05:00 Cyrille Henry <ch@chnry.netmailto:ch@chnry.net>:
Le 13/11/2014 11:10, João Martins a écrit : Hi there, list!
Besides using PD for sound design and programming/composition tools, I've always thought it could be a great platform for "show control", replacing commercial apps like Qlab and others. For those of you who are not familiar with this sort of tools, they are built to streamline the process of "cueing" a performance (theater is my main focus). Cues can be playing, pausing, fading in or out given audio files (and panning, filtering, etc), sending out DMX or MIDI signal for light consoles, as well as playing, pausing, fading in or out given video files. Live video and audio are also possibilities. Each function is apparently simple to implement and I've used some experimental patches in shows of my own, but I've met some resistance from "conventional" technicians. Some testing with Qlab, has led me to the conclusion that a Pd solution could be built and useful, but it would need a simpler GUI for the final control aspects, to resemble as close as possible existing paradigms (some sort of hybrid between an audio mixing board and the normal controls on a CD/audio player, the cueing principles of lighting systems and existing video mixing consoles). A modular system would be perfect for this, and I'm trying to figure out how to start. With such a broad community of users, I'm sure some attempts at this have already been made and I'm not interested in reinventing the wheel. So, if any of you can point me to existing projects with similar features and objectives I'd appreciate it and try to contribute as best as I can.
you can have a look at my "linear cue system"
http://www.chnry.net/ch/?094-Linear-cue-system&lang=en
nothing special, but it fit my needs.
cheers c
Thank you all,
João Martins
-- João Pedro Martins música . web design http://joaomartins.entropiadesign.org mail: joaomartins@mac.commailto:joaomartins@mac.com <mailto:joaomartins@mac.commailto:joaomartins@mac.com> skype: joaopsmartins ichat: joaomartins msn: joaopsmartins
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Alexandre Quessy - 亚历山大 - ألكسندر http://alexandre.quessy.net - Artiste en nouveaux médias http://perte-de-signal.org - Membre de Perte de signal http://sourcelibre.net - Développement logiciel et conception de sites Web http://labalab.ca - Impliqué dans LabàLab - communauté de pratique en arts numériques
On 17/11/14 04:53, Pagano, Patrick wrote:
I would love to see this idea expanded or developed. The issue i have run into over and over again is that pd would need to be CUED from patch to patch so one could design a linear show. I have not seen this possible the way it's designed. For this reason i use Isadora,
I often trigger one patch from another, on the same machine or other machines ... or trigger many patches from a single simple master patch used to run a show, with just the cues and/or follow-ons plus maybe an overall volume or such that gets sent to all the patches. Essentially it is very easy to make a single interface patch to do the kinds of things Isadora and others have as a built-in GUI layer. I usually use [netsend], it is almost as straightforward as [send] locally, and fairly trival onto a local network. But there are other options. The fact that I can trigger to and from scripts in exactly the same way, using pdreceive, is great.
I have not used Isadora for many many years .... I switched to Pd exactly because I was frustrated with the limitations the built-in workflows, GUIs and assumptions imposed, and the frustrating inflexibility of OSX ... Isadora is designed for and tested with a particular workflow and if that matches your own workflow then it may be a very sensible choice for you, likewise for choosing OSX ... one big advantage of that built-in approach is exactly that it is limited to the commonly needed features and hence it is always familiar, and requires less configuration and less under-the-hood knowledge than a more general and flexible system.
Simon
We've been very interested in implementing a custom show runner with a focus on making cues for reliable routing of multichannel audio and multichannel video. I built a player in Max6 to get 3ch video 2ch audio for somebody's show and it ran pretty well. However, when trying to implement the same code for a piece that relied on having very consistent, very smooth HD video, we couldn't maintain a consistent framerate. Ultimately, we used QLab, but we'd prefer to not need their expensive licenses.
I'd be interested to know benchmarks for multichannel audio and HD video playback using Pd/GEM. We hadn't investigated it since I assumed Jitter rendering to GPU with HAP should be better than what GEM can do, but I would be ecstatic to go to Pd for this if the playback performance was good.
Thanks, -Stephen
On Sun, Nov 16, 2014 at 8:56 PM, Simon Wise simonzwise@gmail.com wrote:
On 17/11/14 04:53, Pagano, Patrick wrote:
I would love to see this idea expanded or developed. The issue i have run into over and over again is that pd would need to be CUED from patch to patch so one could design a linear show. I have not seen this possible the way it's designed. For this reason i use Isadora,
I often trigger one patch from another, on the same machine or other machines ... or trigger many patches from a single simple master patch used to run a show, with just the cues and/or follow-ons plus maybe an overall volume or such that gets sent to all the patches. Essentially it is very easy to make a single interface patch to do the kinds of things Isadora and others have as a built-in GUI layer. I usually use [netsend], it is almost as straightforward as [send] locally, and fairly trival onto a local network. But there are other options. The fact that I can trigger to and from scripts in exactly the same way, using pdreceive, is great.
I have not used Isadora for many many years .... I switched to Pd exactly because I was frustrated with the limitations the built-in workflows, GUIs and assumptions imposed, and the frustrating inflexibility of OSX ... Isadora is designed for and tested with a particular workflow and if that matches your own workflow then it may be a very sensible choice for you, likewise for choosing OSX ... one big advantage of that built-in approach is exactly that it is limited to the commonly needed features and hence it is always familiar, and requires less configuration and less under-the-hood knowledge than a more general and flexible system.
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 17/11/14 17:57, Stephen Lucas wrote:
We've been very interested in implementing a custom show runner with a focus on making cues for reliable routing of multichannel audio and multichannel video. I built a player in Max6 to get 3ch video 2ch audio for somebody's show and it ran pretty well. However, when trying to implement the same code for a piece that relied on having very consistent, very smooth HD video, we couldn't maintain a consistent framerate. Ultimately, we used QLab, but we'd prefer to not need their expensive licenses.
I'd be interested to know benchmarks for multichannel audio and HD video playback using Pd/GEM. We hadn't investigated it since I assumed Jitter rendering to GPU with HAP should be better than what GEM can do, but I would be ecstatic to go to Pd for this if the playback performance was good.
Video playback is very hardware dependent, GEM uses openGL so what you can output depends on the GPU, the drivers for this, and the speed of your media drives and the speed of the available transfer to the GPU.
Depending on the cueing and sync requirements it can be much easier to run 1 smaller computer for each video output, but for very tight sync a single computer may be better.
I have been using Raspberry Pis recently to run multiple projection screens, at $40 or so each they can deliver 1 HDMI output with stereo HDMI audio, at 1024p resolution and can be be cued via ethernet using a pd patch. Some other machine could run as many audio channels as you want, and the cues. Audio channels are limited by your audio hardware/budget.
Raspberries not the easiest path, GEM is not much use (yet?) since they use openGL-ES, and really this is about the limit of their capabilities and will need careful tuning for good performance. I put together an external for pd that will load a media file in a paused state, then play it very tightly on a cue using DBUS, I used it last week and I'm in the process of cleaning it up to share. I achieved projection mapping and some alpha overlays on an earlier version of the show, but ran into the GPU limits as far as resolution and such was concerned and fell back on this approach.
The same idea is much much more easily achieved using more powerful (and expensive) devices, and GEM.
For many years I have been using old mac minis as the playback units, using one for master timing and audio playback it is easy to use a metro to play each machine frame by frame and keep video-frame-accurate playback and cues across as many projectors as you have minis. The first time I did this was 8 years ago, with a 5 projector installation making a single very wide HD image of a dancer moving across the whole field so frame accuracy and audio sync was very critical. All the capabilities in GEM are of course available for mapping, effects and such. You will want a dedicated ethernet switch for the LAN so nothing interferes with the communications. Even G4 mac minis can deliver multiple audio channels and multiple video layers, this is well within the capabilities of reasonably priced machines today.
Another approach depends on a single powerful machine. Using technology available in 2007 (but not cheaply!) I used a PCI based industrial video grabber card which could deliver 4 composite video streams (selected in pd from its 16 composite inputs) to the GPU without much CPU use at all, then with SATA drives I could add HD media playback ... I gave up testing at 12 alpha layers with mapping (some HD, some camera, some generated scrolling text etc with fades and playback all completely smooth). It was all achieved in pd with the user interface entirely via a midi fader board. I had set this linux box up because I was projecting live camera images behind the actors speaking and needed close to lip-sync with the performer ... the only possible way was a PCI frame grabber like this, the cameras were old and not gen-locked but the delay was always between 1/2 and 1 1/2 frames so it worked out fine. Firewire or any other transport was useless since there was too much buffering hence unusable latency.
Graphics cards are much more powerful now, though getting that kind of connection into a machine and directly to the GPU will take a careful selection of motherboards. The machine was also used at other times to run 4 DVI outputs (it had 2 linked Nvidia cards) from this vision mixer, it toured through many venues in the hands of a non-computer, very much analogue video guy without any need for my intervention ... it was all extremely stable and comfortable for traditionally trained theatre techs to handle.
Simon
regarding benchmarking between Pd and Max, I tried the two to do real time video mapping and Gem was faster and easier to customized to reach best result. for example, with Max and an IIDC camera you can't easily use the non-standard image format and get more than 60fps. This is easily possible in Pd. and concerning the OS, on the same machine (Macpro 2011), the same Pd patch run approximately 20% faster on Ubuntu than on Mac OS. also, the screen refresh rate is not easy to tweak and AFAIR you can't disable vertical sync on OS X.
-- do it yourself http://antoine.villeret.free.fr
2014-11-17 10:24 GMT+01:00 Simon Wise simonzwise@gmail.com:
On 17/11/14 17:57, Stephen Lucas wrote:
We've been very interested in implementing a custom show runner with a focus on making cues for reliable routing of multichannel audio and multichannel video. I built a player in Max6 to get 3ch video 2ch audio for somebody's show and it ran pretty well. However, when trying to implement the same code for a piece that relied on having very consistent, very smooth HD video, we couldn't maintain a consistent framerate. Ultimately, we used QLab, but we'd prefer to not need their expensive licenses.
I'd be interested to know benchmarks for multichannel audio and HD video playback using Pd/GEM. We hadn't investigated it since I assumed Jitter rendering to GPU with HAP should be better than what GEM can do, but I would be ecstatic to go to Pd for this if the playback performance was good.
Video playback is very hardware dependent, GEM uses openGL so what you can output depends on the GPU, the drivers for this, and the speed of your media drives and the speed of the available transfer to the GPU.
Depending on the cueing and sync requirements it can be much easier to run 1 smaller computer for each video output, but for very tight sync a single computer may be better.
I have been using Raspberry Pis recently to run multiple projection screens, at $40 or so each they can deliver 1 HDMI output with stereo HDMI audio, at 1024p resolution and can be be cued via ethernet using a pd patch. Some other machine could run as many audio channels as you want, and the cues. Audio channels are limited by your audio hardware/budget.
Raspberries not the easiest path, GEM is not much use (yet?) since they use openGL-ES, and really this is about the limit of their capabilities and will need careful tuning for good performance. I put together an external for pd that will load a media file in a paused state, then play it very tightly on a cue using DBUS, I used it last week and I'm in the process of cleaning it up to share. I achieved projection mapping and some alpha overlays on an earlier version of the show, but ran into the GPU limits as far as resolution and such was concerned and fell back on this approach.
The same idea is much much more easily achieved using more powerful (and expensive) devices, and GEM.
For many years I have been using old mac minis as the playback units, using one for master timing and audio playback it is easy to use a metro to play each machine frame by frame and keep video-frame-accurate playback and cues across as many projectors as you have minis. The first time I did this was 8 years ago, with a 5 projector installation making a single very wide HD image of a dancer moving across the whole field so frame accuracy and audio sync was very critical. All the capabilities in GEM are of course available for mapping, effects and such. You will want a dedicated ethernet switch for the LAN so nothing interferes with the communications. Even G4 mac minis can deliver multiple audio channels and multiple video layers, this is well within the capabilities of reasonably priced machines today.
Another approach depends on a single powerful machine. Using technology available in 2007 (but not cheaply!) I used a PCI based industrial video grabber card which could deliver 4 composite video streams (selected in pd from its 16 composite inputs) to the GPU without much CPU use at all, then with SATA drives I could add HD media playback ... I gave up testing at 12 alpha layers with mapping (some HD, some camera, some generated scrolling text etc with fades and playback all completely smooth). It was all achieved in pd with the user interface entirely via a midi fader board. I had set this linux box up because I was projecting live camera images behind the actors speaking and needed close to lip-sync with the performer ... the only possible way was a PCI frame grabber like this, the cameras were old and not gen-locked but the delay was always between 1/2 and 1 1/2 frames so it worked out fine. Firewire or any other transport was useless since there was too much buffering hence unusable latency.
Graphics cards are much more powerful now, though getting that kind of connection into a machine and directly to the GPU will take a careful selection of motherboards. The machine was also used at other times to run 4 DVI outputs (it had 2 linked Nvidia cards) from this vision mixer, it toured through many venues in the hands of a non-computer, very much analogue video guy without any need for my intervention ... it was all extremely stable and comfortable for traditionally trained theatre techs to handle.
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Antoine .. I eventually tamed dbus on the Pis as a pd external (as we spoke about a while ago), but it took a while!
I'll share shortly, still very task specific, but also coded with flexibility in mind, it is a good template now. Dbus in C is messy. It can make a generic dbus external without too much more work.
Simon
ok cool
i need it to build a synchronized audio/video player a solution exist with Python, but it's stuck in a very old Raspbian version... and not compatible with Jessie (and also I don't know anything about Python :-) )
let me know cheers a
-- do it yourself http://antoine.villeret.free.fr
2014-11-17 11:06 GMT+01:00 Simon Wise simonzwise@gmail.com:
Antoine .. I eventually tamed dbus on the Pis as a pd external (as we spoke about a while ago), but it took a while!
I'll share shortly, still very task specific, but also coded with flexibility in mind, it is a good template now. Dbus in C is messy. It can make a generic dbus external without too much more work.
Simon
On 17/11/14 21:10, Antoine Villeret wrote:
ok cool
i need it to build a synchronized audio/video player a solution exist with Python, but it's stuck in a very old Raspbian version... and not compatible with Jessie (and also I don't know anything about Python :-) )
I've avoided all the desktop libraries for dbus, just using its basic interface and a dedicated dbus session so compatibility should be fine. I'm using a custom rt kernel with support for the wolfson in a fairly recent (still wheezy) publicly released raspbian, and also in the B+ release of raspbian as well.
I was using a wolfson audio card, and have not been able to get a reliable player going that will send audio playback from an AV file into userspace, so I needed to cue audio and video independently in pd. It was tight enough for this media, still have to test exactly how tight it is though. It would be better to have a player that can do it directly, and will give that a go. But that may not be available with what broadcom has released so far, that may be why wolfson seemed to stall in its development, and got cheaper.
Next step is getting the wolfson clock sync controls worked out, then I should be able to daisy-chain the spdiff of several wolfsons and essentially have a single media/audio clock running all the Pis and a stereo audio mix to the final wolfson in the chain.
Simon
Hello,
2014-11-17 5:10 GMT-05:00 Antoine Villeret antoine.villeret@gmail.com:
i need it to build a synchronized audio/video player a solution exist with Python, but it's stuck in a very old Raspbian version... and not compatible with Jessie (and also I don't know anything about Python :-) )
I would be curious to see this the code for this solution.
You can use GStreamer with some backend such as Clutter, or GTK+. They work very well. That requires a bit of coding, of course. I have a few of them under my Github user aalex. VLC is another higher-level option. (it's highly scriptable)
Alexandre Quessy - 亚历山大 - ألكسندر http://alexandre.quessy.net - Artiste en nouveaux médias http://perte-de-signal.org - Membre de Perte de signal http://sourcelibre.net - Développement logiciel et conception de sites Web http://labalab.ca - Impliqué dans LabàLab - communauté de pratique en arts numériques
On 17/11/14 17:57, Stephen Lucas wrote:
Ultimately, we used QLab, but we'd prefer to not need their expensive licenses.
If it is cost that concerns you, you live anywhere with western prices and you take any account of your time and the time to teach a new interface to operators ... then DIY with pd is much more expensive than a few hundred dollars buying a ready made, well tested and familiar solution that does what you need ... unless you are going to deploy your system very widely.
You can do many things with pd that you cannot with a standard cueing system
Simon