Using Raspberry-Pi for DMX recording / playback?

[Greenalien]

Using OLA with the Raspberry-Pi, would it be straightforward to intercept the incoming Artnet / E1.31 signal and store it to the SD card for later playback? Most commercially-available DMX record/playback units will only record a limited number of channels or cost a lot of money - it would be great to be able to record several universes at once, and then play them back.

[nico]

This is the greatest idea of the week ;-)

+1

Le 14/09/12 12:16, Greenalien a �crit :

> --
> open-l...@googlegroups.com /
> http://groups.google.com/group/open-lighting
> To unsubscribe email open-lightin...@googlegroups.com

[Andrew Frazer]

Been contemplating this myself. :-) It needs a few little add-ons, like being able to record time code at the same time. 16 Universes would be my target per PI.

Would be happy to sponsor this project.

On 14/09/2012, at 10:56 PM, nico <sl12...@gmail.com> wrote:

> This is the greatest idea of the week ;-)
>
> +1
>

> Le 14/09/12 12:16, Greenalien a écrit :

[RenZO]

You can already record in OLA !
For example, set your artnet input ports on universes 1,2,3,4:
ola_recorder -r MyRecord -u 1,2,3,4

Then you can play it back.
Find all options with ola_recorder -h
Simon, I noticed the help is not returned when no arguments are given.

RenZO

[Peter Stuge]

RenZO wrote:
> I noticed the help is not returned when no arguments are given.

Maybe you can send a patch?


//Peter

[RenZO]

I will try to do so :)

RenZO

[Greenalien]

You can already record in OLA !

This is great news - is there any way to control it from the web interface? Otherwise, how do you type in ola_recorder -r MyRecord -u 1,2,3,4 as there is no command line once olad is started.

Then you can play it back.

Is there, or will there, be any way to vary the playback speed?

 16 Universes would be my target per PI.

That would be good, is there a limit at present?

[RenZO]

On Friday, September 14, 2012 6:43:35 PM UTC+2, Greenalien wrote:

You can already record in OLA !

This is great news - is there any way to control it from the web interface? Otherwise, how do you type in ola_recorder -r MyRecord -u 1,2,3,4 as there is no command line once olad is started.

Then you can play it back.

Is there, or will there, be any way to vary the playback speed?

There is not, however it could be added.
At the moment it records the time between each frame so the playback is at the same speed as the record.
Also, I've seen the times recorded are not always regular, so it could be good to force the framerate at 40 fps for example.
I will try to make this change :)

At the moment I just made a small change about the help thing:
http://code.google.com/r/renzokiller-ola/source/list

 

 16 Universes would be my target per PI.

That would be good, is there a limit at present?

I don't think so.

RenZO

[Greenalien]

Renzo - I'm still not clear how to run it - if olad is running, I don't have a command line, so I can't enter any ola commands.

[RenZO]

You can try to do: olad -f
Then you will have the command line.

[Greenalien]

Thanks - I can now enter the commands, I look forward to trying it out.
Cheers...John

[Andrew Frazer]

What i'd like to do is add to be able to record time code along side the the art-net / dmx frames.    At play time, i'd like to be able to make OLA jam along with Time code again.

Off to find a Time code package i guess.

[Andrew Frazer]

I'm just trying to get my head around this problem.   I want to be able to "record" say 16 Universes of Art-net ( or sACN ) and store that.   Then replay it later back onto the network..  In esense making the OLA a "media" server of types.

Whats limiting the input ports to 4?     I note that in both Art-net and E1.31 that both input and outputs are limited to only 4 universe each.

We have to of course to some trickery to get the actual art-net packets to arrive at the OLA device.  I'm thinking that for "recording" that instead of unicasting my art-net to my end "devices", they will be sent out of the media server

in broadcast.   We'll record all those packets, and then will need to parse the packets through a "routing" table,  and send them out in unicast in stead.

[Hippy]

On Sun, Sep 16, 2012 at 2:27 PM, Andrew Frazer <andrew...@stellascapes.com> wrote:

I'm just trying to get my head around this problem.   I want to be able to "record" say 16 Universes of Art-net ( or sACN ) and store that.   Then replay it later back onto the network..  In esense making the OLA a "media" server of types.

Whats limiting the input ports to 4?     I note that in both Art-net and E1.31 that both input and outputs are limited to only 4 universe each.

have a look at this post re the 4 port limit:
https://groups.google.com/forum/#!searchin/open-lighting/16$20universes/open-lighting/vWRuwsFpbu4/LRJ3FYkstOgJ
 

[Andrew Frazer]

" Also OLA strictly conforms to the ArtNet spec. This means that it's 

limited to 4 input or 4 output ports at once. There are tricks you can 
play with multihoming to support more than 4 ports, but OLA doesn't 
support that (libartnet does however). "

i've missed something then.    Almost all the  console/media servers  I use are able to send many many more than 4 universes of data, and the server only has 1 IP, so its not multihoming..  Are they not Art-net compliant.

Anyway, its looking like OLA wont' ( at least out of the box ) support grabbing more than 4 universes, ( or playing them ) at a time.. Or have i missed something..

All ears if someones got a good idea..

[Peter Stuge]

Andrew Frazer wrote:
> We have to of course to some trickery to get the actual art-net
> packets to arrive at the OLA device. I'm thinking that for
> "recording" that instead of unicasting my art-net to my end
> "devices", they will be sent out of the media server
> in broadcast.

That's one way, but more work.

I would suggest to use networking equipment which allows to send all
traffic out to a monitor port.

The interface connected to that port must of course be in promiscuous
mode, and OLA may not neccessarily be able to receive the packets
without (small) modification, but I think it would be easier than to
implement some kind of address translation after the fact.


//Peter

[Andrew Frazer]

Yes, we could do that as well.. Thats actually very simple to do with any half decent managed switch. It could be done with something like ethereal. Packets could be replayed with any number of pcap players..

Have actually been there and done this.. The results end up being pretty scraggly…

[Hippy]

On Sun, Sep 16, 2012 at 4:10 PM, Andrew Frazer <andrew...@stellascapes.com> wrote:

" Also OLA strictly conforms to the ArtNet spec. This means that it's 

limited to 4 input or 4 output ports at once. There are tricks you can 
play with multihoming to support more than 4 ports, but OLA doesn't 
support that (libartnet does however). "

Well, since the OLA plugin creates a 'to-spec' ArtNet node, not a controller, then it's on the money.  But I totally hear you, as most products with more than 4 out ports are not compliant.  I think a ArtNet controller can send as many universes as it likes.

MA, ChamSys, etc... have 16 universes for breakfast.

You could use a different protocol, like ESP-Net, which has no such limitation.

I second the need for a --non-compliant ArtNet node, but I don't know how simon would feel about it.

Would it be simply changing:

enum { ARTNET_MAX_PORTS = 4; }
in pluggins/artnet/ArtNetPackets.h?

Cheers,

hip

 

[Andrew Frazer]

We manufacture RGB LED pixel controllers,  and they are non-compliant in respect of the fact we *support* up to 8 universes on a single device, and it works up to about 16 before it runs out of processing power. Its a (60Mhz Pic Micro folks)..  

The problem comes when *standards* get in the way of getting a job done.   Art-net has to be one of the worst *standards* anyway, so it deserves to be ignored :-)

So, even if we don't look at Art-net,   if i try using E1.31 ports,   there still is a limit of 4 ports..

Did you try messing with the MAX ports and see what happens?    I'm just currently running OLA on a Raspberry PI, and don't' have a dev environment set up, but i guess we might have to do that.

Maybe in 

/sensible/compliant/standards.h we could have a switch

{ STANDARDS = IGNORE; }

[Peter Stuge]

Andrew Frazer wrote:
> Yes, we could do that as well.. Thats actually very simple to do
> with any half decent managed switch. It could be done with
> something like ethereal. Packets could be replayed with any number
> of pcap players..

I didn't mean libpcap, but still let OLA or another Art-Net software
receive and interpret packets, and save the sequence in some way it
can use for playback later.

> Have actually been there and done this.. The results end up being
> pretty scraggly

What does scraggly mean? :)

I would actually expect the pcap approach to work well at least with
some network adapters. But I think a slightly higher level approach
would work better.


//Peter

[Andrew Frazer]

Scraggly is a real word!! In this context; it means "untidy"

[Simon Newton]

On Sat, Sep 15, 2012 at 11:56 PM, Andrew Frazer
<andrew...@stellascapes.com> wrote:
>
> We manufacture RGB LED pixel controllers, and they are non-compliant in
> respect of the fact we *support* up to 8 universes on a single device, and
> it works up to about 16 before it runs out of processing power. Its a (60Mhz
> Pic Micro folks)..
>
> The problem comes when *standards* get in the way of getting a job done.
> Art-net has to be one of the worst *standards* anyway, so it deserves to be
> ignored :-)
>
> So, even if we don't look at Art-net, if i try using E1.31 ports, there
> still is a limit of 4 ports..

It should be 5 E1.31 ports, see
http://code.google.com/p/open-lighting/source/search?q=NUMBER_OF_E131_PORTS&origq=NUMBER_OF_E131_PORTS&btnG=Search+Trunk

It should be a pretty simple change for someone to make this into a
config file option.

I've never really liked the static port model and I'd prefer a system
where you can create ports dynamically. That would require quite a
significant re-write of all the APIs.

>
>
> Did you try messing with the MAX ports and see what happens?

Don't change that or you'll start sending malformed ArtNet packets.

Simon

[Simon Newton]

On Sat, Sep 15, 2012 at 11:10 PM, Andrew Frazer
<andrew...@stellascapes.com> wrote:
>
> " Also OLA strictly conforms to the ArtNet spec. This means that it's
> limited to 4 input or 4 output ports at once. There are tricks you can
> play with multihoming to support more than 4 ports, but OLA doesn't
> support that (libartnet does however). "
>
>
> i've missed something then. Almost all the console/media servers I use
> are able to send many many more than 4 universes of data, and the server
> only has 1 IP, so its not multihoming.. Are they not Art-net compliant.

Sending isn't a problem since it doesn't matter if you can represent
all the input ports in an ArtPollReply packet. It's receiving ArtNet that's
the issue.

[Andrew Frazer]

On 17/09/2012, at 4:18 AM, Simon Newton <nom...@gmail.com> wrote:

> On Sat, Sep 15, 2012 at 11:10 PM, Andrew Frazer
> <andrew...@stellascapes.com> wrote:
>>
>> " Also OLA strictly conforms to the ArtNet spec. This means that it's
>> limited to 4 input or 4 output ports at once. There are tricks you can
>> play with multihoming to support more than 4 ports, but OLA doesn't
>> support that (libartnet does however). "
>>
>>
>> i've missed something then. Almost all the console/media servers I use
>> are able to send many many more than 4 universes of data, and the server
>> only has 1 IP, so its not multihoming.. Are they not Art-net compliant.
>
> Sending isn't a problem since it doesn't matter if you can represent
> all the input ports in an ArtPollReply packet. It's receiving ArtNet that's
> the issue.

Right, so if i read you correctly;

The 4 outputs are just a limitation of OLA?

[Simon Newton]

Correct.

[Andrew Frazer]

Thats like saying "wet paint" or "don't push the red button".

Whats going to be malformed?

>>
>>
>> Did you try messing with the MAX ports and see what happens?
>
> Don't change that or you'll start sending malformed ArtNet packets.
>
>>
>>

[Simon Newton]

On Sun, Sep 16, 2012 at 12:12 PM, Andrew Frazer
<andrew...@stellascapes.com> wrote:
> Thats like saying "wet paint" or "don't push the red button".
>
> Whats going to be malformed?

In the ArtPollReply packet, the fields PortTypes, GoodInput,
GoodOutput, Swin & Swout won't be 4 bytes each in length.

Simon

>
>
>
>
>
>>>
>>>
>>> Did you try messing with the MAX ports and see what happens?
>>
>> Don't change that or you'll start sending malformed ArtNet packets.
>>
>>>
>>>
>>> Would it be simply changing:
>>>
>>> enum { ARTNET_MAX_PORTS = 4; }
>>> in pluggins/artnet/ArtNetPackets.h?
>>>
>

[Andrew Frazer]

But if my "sender" of data doesn't care then this might not be a problem anyway.. because it won't be using art-net polls to build up its "picture" of where Universes should go. The media server will be "statically" mapped.

Ie, Universe 10 ----> unicasted to 10.10.10.10


My guess now is that OLA however relys on getting art-net poll replys so it can build up its art-net routing table?

[Simon Newton]

On Sun, Sep 16, 2012 at 1:28 PM, Andrew Frazer
<andrew...@stellascapes.com> wrote:
>
> But if my "sender" of data doesn't care then this might not be a problem anyway.. because it won't be using art-net polls to build up its "picture" of where Universes should go. The media server will be "statically" mapped.

The sender doesn't care, but anything trying to identify & locate
ArtNet nodes will. If you're going to go down this path it would be
better not to send ArtPollReplies at all rather than send malformed
packets.

> Ie, Universe 10 ----> unicasted to 10.10.10.10
>
>
> My guess now is that OLA however relys on getting art-net poll replys so it can build up its art-net routing table?

It does unless you switch it into always_broadcast mode.

Simon

[Andrew Frazer]

On 17/09/2012, at 8:32 AM, Simon Newton <nom...@gmail.com> wrote:

> On Sun, Sep 16, 2012 at 1:28 PM, Andrew Frazer
> <andrew...@stellascapes.com> wrote:
>>
>> But if my "sender" of data doesn't care then this might not be a problem anyway.. because it won't be using art-net polls to build up its "picture" of where Universes should go. The media server will be "statically" mapped.
>
> The sender doesn't care, but anything trying to identify & locate
> ArtNet nodes will. If you're going to go down this path it would be
> better not to send ArtPollReplies at all rather than send malformed
> packets.

True.. Time to go looking in the code base and have a look to see how viable it will be to provide a config option to turn off art-net Poll Replies as an option.
Don't really want to end up with a forked bit of code if i can avoid it.

>
>> Ie, Universe 10 ----> unicasted to 10.10.10.10
>>
>>
>> My guess now is that OLA however relys on getting art-net poll replys so it can build up its art-net routing table?
>
> It does unless you switch it into always_broadcast mode.
>

Right.. Also now going to look to see what its going to take to provide another config file with a routing table to be used in place of what it learns.


I know that this probably means that things end up *outside* of spec.

[Douglas Heriot]

If you’re ok with using E1.31 sACN instead, that’ll be the easiest way to get started.

As Simon pointed out, the protocol itself has nothing to do with the number of ports in OLA. You really just have to change one line of code (in plugins/e131/E131Device.h)

http://code.google.com/p/open-lighting/source/search?q=NUMBER_OF_E131_PORTS&origq=NUMBER_OF_E131_PORTS&btnG=Search+Trunk

I think if you want to load the value from the config file instead, it should be easy to modify E131Plugin.cpp

(Andrew, If you’re interested more in the issues around Art-Net port limitations, you might want to read the Art-Net specification:

http://artisticlicence.com/WebSiteMaster/User%20Guides/art-net.pdf

See page 10 for some of the issues)

Douglas

[Andrew Frazer]

I personally would be ok with doing it in sACN.. But.. sadly, most of the places i want to make this work, won't be.  Theres *still* not wide use of sACN..  Hopefully that will change..    For most folks, why change something that isn't broken.

My Pixel controllers speak sACN and Art-net ( different firmware builds, not at the same time ), but we probably on ship 1 ACN for every Art-net.

On 17/09/2012, at 6:31 PM, Douglas Heriot <dougla...@gmail.com> wrote:

If you’re ok with using E1.31 sACN instead, that’ll be the easiest way to get started.

As Simon pointed out, the protocol itself has nothing to do with the number of ports in OLA. You really just have to change one line of code (in plugins/e131/E131Device.h)

http://code.google.com/p/open-lighting/source/search?q=NUMBER_OF_E131_PORTS&origq=NUMBER_OF_E131_PORTS&btnG=Search+Trunk

Your right, it should not be too tricky.

I think if you want to load the value from the config file instead, it should be easy to modify E131Plugin.cpp

I think theres some merit to building a "static" routing table system for both E131 and Artnet, and i think this is probably something that is within my capablitys :-)   My C++ is *very* rusty, as we micro controller folks only use C, but hey, its a good learning thing to do again, and i'm stuck at home on enforced sick live, despite being more healthy than i've been for a while, or another 2 weeks.

[Simon Newton]

On Mon, Sep 17, 2012 at 12:50 AM, Andrew Frazer
<andrew...@stellascapes.com> wrote:
>
>
> I personally would be ok with doing it in sACN.. But.. sadly, most of the
> places i want to make this work, won't be. Theres *still* not wide use of
> sACN.. Hopefully that will change.. For most folks, why change something
> that isn't broken.
> My Pixel controllers speak sACN and Art-net ( different firmware builds, not
> at the same time ), but we probably on ship 1 ACN for every Art-net.
>
> On 17/09/2012, at 6:31 PM, Douglas Heriot <dougla...@gmail.com> wrote:
>
> If you’re ok with using E1.31 sACN instead, that’ll be the easiest way to
> get started.
> As Simon pointed out, the protocol itself has nothing to do with the number
> of ports in OLA. You really just have to change one line of code (in
> plugins/e131/E131Device.h)
> http://code.google.com/p/open-lighting/source/search?q=NUMBER_OF_E131_PORTS&origq=NUMBER_OF_E131_PORTS&btnG=Search+Trunk
>
>
> Your right, it should not be too tricky.
>
>
> I think if you want to load the value from the config file instead, it
> should be easy to modify E131Plugin.cpp
>
>
> I think theres some merit to building a "static" routing table system for
> both E131 and Artnet, and i think this is probably something that is within
> my capablitys :-) My C++ is *very* rusty, as we micro controller folks
> only use C, but hey, its a good learning thing to do again, and i'm stuck at
> home on enforced sick live, despite being more healthy than i've been for a
> while, or another 2 weeks.

I'm not opposed to adding such a mechanism.

Simon

[Andrew Frazer]

The starting point is to probably have a hand edited txt file where the static routing information is contained.. From theres its not a big jump to do this via a web based config.

Where does OLA keep track of what its learnt via art-net polls? And how is the E1.31 stuff being tracked, i'm guessing there is no multicast.

[Hippy]

A static routing table is the elegant solution...

But in the spirit of getting the job done Andrew, I've pushed a nasty little hack into my repo, which allows creating more than 4 ports, though only 4 ports exist in terms of the spec, so the ArtReply packet only has the first 4 defined.

You can patch on port > 4, though not subscribe to a unicast universe, or be subscribed to, so only useful for broadcast really (always_broadcast = true) I suppose.

It also means, some devices may not acknowledge the universes we are broadcasting.
But i'd bet most would.

It's not to spec, but seems to work if you want to use more universes.

http://code.google.com/r/dmxout-dev/source/detail?r=b41fd978ae84338ccddbc5e1c7b01a1cc8898726

I don't expect it to be accepted into OLA as it's very hacky McHackhack, but might help you in the short term - but possibly not in the long term... that's your call.


Specs are great, but if your working with not-to-spec equipment, you'd still rather it work  than needing a spec to define how to handle non-spec implementations...

[Simon Newton]

On Mon, Sep 17, 2012 at 11:54 PM, Andrew Frazer
<andrew...@stellascapes.com> wrote:
>
>
> The starting point is to probably have a hand edited txt file where the static routing information is contained.. From theres its not a big jump to do this via a web based config.
>
> Where does OLA keep track of what its learnt via art-net polls?

http://code.google.com/p/open-lighting/source/browse/plugins/artnet/ArtNetNode.h,
in the InputPort struct there is a subscribed_nodes map.

> And how is the E1.31 stuff being tracked, i'm guessing there is no multicast.

E1.31 is only multicast so there is no tracking.


Simon

[Simon Newton]

On Tue, Sep 18, 2012 at 12:47 AM, Hippy <dmx...@gmail.com> wrote:
> A static routing table is the elegant solution...
>
> But in the spirit of getting the job done Andrew, I've pushed a nasty little
> hack into my repo, which allows creating more than 4 ports, though only 4
> ports exist in terms of the spec, so the ArtReply packet only has the first
> 4 defined.
>
> You can patch on port > 4, though not subscribe to a unicast universe, or be
> subscribed to, so only useful for broadcast really (always_broadcast = true)
> I suppose.
>
> It also means, some devices may not acknowledge the universes we are
> broadcasting.
> But i'd bet most would.
>
> It's not to spec, but seems to work if you want to use more universes.
>
> http://code.google.com/r/dmxout-dev/source/detail?r=b41fd978ae84338ccddbc5e1c7b01a1cc8898726

Please do these changes in a branch, because now I have to cherry pick
in the testing changes while avoiding the artnet change.

[Andrew Frazer]

Grrr.. One of the worst constructed sentences in a long time in my past. I meant to say i'm guessing there is no tracking since it was multicast.
The standard provides for E1.31.

Regads

Andrew.

[Andrew Frazer]

The standard provides for unicast E1.31 packets to be sent as well.. And then you would need a something to store them.

Regards

Andrew.

[Andrew Frazer]

Although universes are mapped to specific Multicast Groups.. i.e. universe 1 is 239.254.0.1 universe 2 is 239.254.0.2 does OLA rely on this, or does it use the universe field that is in the packet.

I'm about to dive head long into the code.1

[Hippy]

OK, i'll undo those changes and tidy up the test changes in the next day or so.

Cheers,

[Andrew Frazer]

This is quite useful, its got past the 4 port limit..   This coupled up with the static routing table, turns into a useful solution.

[Simon Newton]

On Tue, Sep 18, 2012 at 12:40 PM, Andrew Frazer
<andrew...@stellascapes.com> wrote:
>
>
> Although universes are mapped to specific Multicast Groups.. i.e. universe 1 is 239.254.0.1 universe 2 is 239.254.0.2 does OLA rely on this, or does it use the universe field that is in the packet.

Only the universe field is checked. It doesn't look at the dest IP at all.

> I'm about to dive head long into the code.1
>
>
>
>
> On 19/09/2012, at 7:21 AM, Andrew Frazer <andrew...@stellascapes.com> wrote:
>
>>
>> Grrr.. One of the worst constructed sentences in a long time in my past. I meant to say i'm guessing there is no tracking since it was multicast.
>> The standard provides for E1.31.
>>
>> Regads
>>
>> Andrew.
>>
>>
>>
>>> And how is the E1.31 stuff being tracked, i'm guessing there is no multicast.
>>
>> E1.31 is only multicast so there is no tracking.
>>
>>>
>>
>

[Andrew Frazer]

Cool.. Thats not only good its "standards" compliant, but i didn't expect anything different from you sir! Of course the IP addressing is very important so that IGMP and IGMP snooping works..

[Hippy]

Simon, do you think maybe my hack could make it in, as a source level configuration option, for those who want such an arrangement (like me and maybe andrew)?   Or maybe you can see a different approach to achieve the same goal?

 

Cheers,

[Andrew Frazer]

Im not sure if its something that is good to do at a source level config option as opposed to a run time configuration option..     Very much trying to prevent forks of code here, because that gets really messy very quickly!!

E1.31 And Multicast is making the problem much much simpler of course to get all the data where it needs to be!!!

[Andrew Frazer]

Is there anyone interested in working on this as a paid job.. the end result will end up back in the project..  Contact me directly if you are interested.

[Mark Godfrey]

Sorry to dredge up an older thread, but did this get resolved? Is there now a way to record more universes? Did you find a way to sync playback across Pis with time code?

[Andrew Frazer]

Yes, but no.  I've ditched Raspberry Pi's because the hardware is just a bit 'whimsy'.    ( Power supply issues make it less than 100% bombproof. Its ok for messing with, i just don't' trust it enough to use for a show in a pro environment ).         Yes, You can record lots of universes with OLA now.    

I've tracked down a solution that uses some OLA stuff, and a lot of other external stuff.       Some of it will get ( hopefully ) merged back into OLA. Unforuatly our development is about 150 commits behind the mainline now and it doesn't merge cleanly.  When we have some time we'll see how it goes.

And yes, we did find not only an "interested" person, but a very good person who now is part of our team..  

Sorry probably not not the answer you want.

--
The Open Lighting Group: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Mark Godfrey]

Thanks for the reply. Glad things are progressing.
Any chance of getting hold of that forked code?
Completely understand if not.
BR