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). 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. 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. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-------------------------------------------------------------------------| | A successful tool is one that was used to do something undreamed of | | by its author. | | -- S.C. Johnson | |-------------------------------------------------------------------------| _______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
