On Tuesday 21 May 2013 14:37:09 Fred Gleason wrote: > On May 21, 2013, at 13:53 39, drew Roberts wrote: > > I am still a bit comfused though. Isn't a macro basically something in a > > macro cart that would need to "play" for anything to happen? > > That is one way RML can be used. It can also be executed asynchronously, > outside of any log context. That's what rmlsend(1) is all about. It can > also be generated within the system in response to various user-defined > events (e.g. see RDAdmin->ManageHosts->RDAirPlay).
I knew this but was not remembering it when writing. I think possibly because I have had little need for it in the past. > > On May 20, 2013, at 18:27 35, drew Roberts wrote: > > Let's call this modified now and next feature "full now and next" and it > > will be now and next for every audio event that goes on air and perhaps > > we will need some non-playout audio events to handle live reads for > > instance. > > Hence RML. That's how we handle 'non-playout audio events'. A 'full now > and next' compliant system merely needs to send the appropriate RML to > Rivendell. Now I know we are officially miscommunicating. Probably because of: "Either I was unclear in my explanation (very possible)" OK, so I was more talking of things in the log that are say a stop for a live read, etc. (not sure what etc would be exactly atm) and that the log would know of but would not normally send a regular now and next for. Also commercials which one we would not normally wanting showing in our regular now and next processing. We don't want them in the stream metadata or on the web page, etc. I think I can see how the RML feature you mention would also be useful for things which the outside knows of that the log does not. I was thinking more of things that the log does know of but which should not go to a normal now and next and may not even be carted audio. > > On May 21, 2013, at 13:53 39, drew Roberts wrote: > > Or is this going to be a rivendell loadable module? (Where going is > > defined here as may or may not happen... ~;-) > > RLMs come in at the other end of the pipe -- they're all about how PAD gets > delivered. I'm talking about ways to *trrigger* a PAD delivery, > independent of the context of a given log machine. > Is that any clearer now? Does anyone think this might be useful? So in one config, rdairplay sends this complete now and next to a special rotter. The special rotter saves hour by hour as normal to one directory tree as normal but also saves named audio (name based on now and next title and artist + start time?) with duration based on now and next time and duration of the now (duration of the now or cut off when the next becomses the now?) in a different directory. In this config we would then have a directory full of files that contain teh playout day broken out by what played when. IN another take on the config, the special rotter could save as a normal rotter and also save an edit decision list and then another web page could show the edl and pull the audio to a created file on demand based on the edl and the stored audio. I spent some time a while back working on a hacked together edl player (IIRC based on vlc) but that was more for listening based on the edl rather than pulling audio out based on it. all the best, drew _______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
