Ah, so it's a particular implementation of an audio logger. Got it. Thanks!
Brian Sent from my iPhone On May 23, 2013, at 8:26 AM, drew Roberts <z...@100jamz.com> wrote: > On Tuesday 21 May 2013 18:30:00 Brian McKelvey wrote: >> What's a rotter? > > http://www.aelius.com/njh/rotter/ > > Something some of us use or have used in a station setup to record things for > a record of what played. >> >> Sent from my iPhone > > drew >> >> On May 21, 2013, at 3:13 PM, drew Roberts <z...@100jamz.com> wrote: >>> 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 >> >> _______________________________________________ >> Rivendell-dev mailing list >> Rivendell-dev@lists.rivendellaudio.org >> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > > > _______________________________________________ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev _______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
