Test it out. http://msp.ucsd.edu/software.html
now, Miller, I haven't seen announcements from Pd-announce for the test
versions as usual, how come?
I have some issues I have to report, by the way.
cheers
Hi,
I don't know about the state of pd/gem on raspi these days, but some
years back I had to synch and control multiple video projections using
raspi3's for a performance (with some diy servo shutter for the video
projectors), and finally used omxplayer (on the framebuffer directly)
and python with OSC control, as it was precise to the frame - the whole
was controlled by a puredata timeline sending command by OSC to make
loops, pause, jumps in the videos ... it worked nicely for days ;)
you can find the messy code here :
https://framagit.org/Olm-e/osc-omxplayer (probably to revise with
current python/omxplayer)
In this it does not support 2 screens directly (raspi3 has only 1), but
omxplayer seems to support it so it's probably a matter of passing the
good arguments to it (--display=2 and --display=7 )
hope it helps ;)
Ol;
From: Simon Iten <itensimon(a)gmail.com>
>
> Hi list,
>
> Has somebody used the two HDMI outs from PD to play two videos on two
> different screens?
>
> I am finding infos from people doing it with omxplayer, but I need it
> synced and looped. Or are there any other Linux video players that can
> sync
> two streams on two different monitors?
Howdy all,
My feeling on this is:
1. Recognize that, despite using "private" or "unstable" internal APIs, people have been using/abusing them for years. (So far, I feel we have been recognizing this by being careful not to break things, more or less.)
2. We should document all internal messaging, at least for the sake of developer documentation. If we lump "user space" and "internal" messaging together in an open manual, then they should be clearly delineated with special placed on emphasizing what things are more or less stable and what things are not. Then the user can decide how they want to proceed. I don't see a problem if people want to play with the internals on their own machine and crash Pd... that's half the fun for such activities anyway (learning).
3. We should get a poll of which internal messages are currently in use and consider which of these could be moved into "user space" and/or replaced by a better API. I believe this thread is already providing a good list...
4. Open a technical discussion on supporting "dynamic patching" officially. It's clearly very useful even if clunky through the current workarounds. Even with [clone] there are still many use cases...
> On Nov 28, 2021, at 12:25 AM, pd-list-request(a)lists.iem.at wrote:
>
> Message: 1
> Date: Sat, 27 Nov 2021 20:20:49 +0100
> From: Jean-Yves Gratius <jyg(a)gumo.fr <mailto:jyg@gumo.fr>>
> To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>
> Subject: Re: [PD] documenting messages to/from Pd and dynamic patching
> Message-ID: <f41bab20-e831-3f04-52fb-ba273b1e0daf(a)gumo.fr <mailto:f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr>>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 27/11/2021 17:19, pd-list-request(a)lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote:
>> ForwardedMessage.eml
>>
>> Subject:
>> Re: [PD] documenting messages to/from Pd and dynamic patching
>> From:
>> Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>>
>> Date:
>> 27/11/2021 ? 17:01
>>
>> To:
>> Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>>
>>
>>
>> Two examples that come to my mind:
>>
>> 1) [iemguts/canvasselect] allows to (de)select objects simply by
>> index. No need to emulate mouse selection with "mouse" and "mouseup".
>>
>> 2) canvases/objects can be moved around with [iemguts/canvasposition]
>> resp. [iemguts/canvasobjectposition]
>>
>> Are there any other use cases for "mouse" and "mouseup"?
>>
> Hi. My 2 cents
>
> Personally, I use mouse and mouseup messages to forward multitouch
> events into the patch, received? from my multitouch linux laptop.
>
> If those messages were blocked, all my multitouch ecosystem would be out
> of order :-) .
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>