-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cart Linking #384
Comments
Meaning what exactly? |
This is a feature that would allow you to have a cart automatically load another cart. For example, you have a cart with cuts introducing a particular song. This cart is then linked to the music cart so each time the intro cart appears in the log it knows to also load the actual music cart next. I was speaking with John Anderson and wanted to make an issue before I forgot. From StationPlaylist:
|
Some design questions to muse over: Would this operate:
What should happen when a linked cart is deleted from a log? Should its linked components be deleted as well? Likewise, when a linked cart is moved or copied. How about when a linked cart is deleted from the Library? What should happen if the user attempts to place a cart in the middle of a linked set? Is some sort of "splitter" facility needed --i.e. place a single component of a linked set without its linked siblings? |
This is really the same problem with voice tracks. What if someone deletes/moves/inserts a cart before or after a voice track? I vote for option 5, when rdairplay(1) figures out which cut it should play. Since the link would happen in near realtime, there isn't much of a window of opportunity for someone to mess it up:
Of course, then a cart just "shows up" in the log. But if the log indicates the link (maybe with some text and a different background color/icon), I don't see that as being an issue. |
So placing a linked cart in rdairplay(1), as opposed to in rdlogedit(1), would have different results? |
No, I don't think there would be a difference. Let's say cart 1000 has a link to cart 2000. Cart 2000 is never added in rdlogedit(1), rdlogmanager(1) or rdairplay(1), cart 1000 is. When rdairplay(1) prepares to play cart 1000 (RDLogPlay::startEvent() or nextEvent()??), it notices that it is linked to 2000 and then loads 2000 to play next. If someone were to delete 1000, 2000 would never play. You wouldn't see 2000 in the log until it was time for it to play next, which may not be desirable, but it more closely mimics the behavior of not knowing which cut is going to play until it's playing. I also think the intended use for the feature is for automatic mode, not manual or live assist. |
Why are we trying to mimic cut selection behavior? |
No other reason than because that's what people are used to. Realtime log changes shouldn't be a surprise and it seems like a reasonable and simple way to handle the cart linking. I'm at a little bit of a loss because this isn't a feature I thought of. I'm trying to create issues for features from conversations and FaceBook so they don't get lost and can be discussed. Unfortunately, it seems not may people visit Github. |
Design discussions like this are often best conducted on one of the mailing lists. In any case, it'd probably be best to defer this one until after the v3.0.1 release. |
Sounds good. |
I do understand that is semi-tabled to v3.0.1, but lets put some thoughts out..... I think the first consideration is the ability to have the linked carts operate as part of a group, that then becomes click-able[selectable] to determine IF the group is allowed to be used. This should allow the operator to determine when and how they want to use the linked carts...(an also when NOT to use them) Some design questions to muse over: Would this operate:
I am assuming you are talking when rdlogmanagers is generating the music log Assuming that the group is selected to used in rdadmin, and the group is part of an selected event which allows it, it becomes allowed. If the event that selects the group is not selected in a particular clock, then it's not used.
Assuming an external scheduler, I would think yes, but stupid scheduling could come from inserting the wrong cart number. In most cases, with folks using external schedulers, they will get this, or not use the feature at all. they just use one set of numbers vs another. either way, it's not complicated
yes, (i would think it would have to to create consistency)
yep What should happen when a linked cart is deleted from a log? Should its linked components be deleted as well? No, as your original music or show cart is actually the 2nd cart, (the cart that the leading cart is linked to), so by that nature, that cart HAS to be produced FIRST!. In my mind, the link is simply an intro, (and if you really want to make you life complicated, a potential outro cart, also linked). On the main cart, there likely needs to be a switch, "Allow Linking to this Cart", although this could be a group thing, too. If the link is deleted, who cares, if you need to play the song without intro, just play the original number. let's assume a cart number of 1000 for the "intro" cart, 2000, for the actual song "Respect, by Aretha Franklin", and 3000, for a potential linked "outro" cart, if you wanted to go that far..{not sure I think that's a great idea yet, but for the sake of discussion}... Also, since I want to use the internal Rivendell scheduler, I am primarily {only} using carts from the 1000 series bank of numbers. which means, I schedule the intro cart to Respect (1000), which plays my carted intro, and since the segue markers are set to allow a talk-over, it immediately rolls over cart 2000, the song, and I talk over it. Obviously, the song just plays out till conclusion. You would not want to schedule cart 2000 after 1000, in the case, the song would play twice. You simply let Rivendell play the "linked cart" for every song you wanted to play. In those cases where you want the song to play, without an intro, you would schedule the 2000 cart, as an event, so the original non linked cart would play. Still trying to figure out exactly how to do the 3000 series cart, which would be an outro to the main cart. In my mind that's looking more and more link a macro, play 2000, then add 3000, or the appropriate outro...that's just not that clear to me yet... Likewise, when a linked cart is moved or copied. it works like it does now..cart 1000, would move it's associated music to that spot How about when a linked cart is deleted from the Library? nothing..as the link is not primary...just the intro's (which I see as a fairly substantial, heavily day-parted multi cut cart, btw) What should happen if the user attempts to place a cart in the middle of a linked set? Cannot do it..FORBIDDEN. Oviously, they can manually play something over it, but that's about it. Is some sort of "splitter" facility needed --i.e. place a single component of a linked set without its linked siblings? I would not think so... the split would be what cart number you actually ran. I don't see any change in the music files at all, and the Intro Group just need to say what the song is , and MAYBE an indicator of what cart it's linked too. Simply put, you schedule from the INTRO group, or the MUSIC Group, and that would determine the way the song is handled... What Happens when ou DELETE the music group song 2000... after a WARNING, it deletes all associated intro, and potentially outro carts... sorry for being so long... |
Is some sort of "splitter" facility needed --i.e. place a single component of a linked set without its linked siblings? I think I was clear on this...but if not.. play cart 1000 = play intro and song together... play cart 2000 = just play the song without any associated intro or outro.... play cart 3000 = play cart 2000, and add talk out or outro at end segue point...this is likely going to be a royal PIA, cause it likely has a mode switch or something to actually make it sound good....I think I can to it with a macro, got to experiment with that one. If you schedule from internal scheduler, use specific events to schedule from INTRO or MUSIC groups as needed. External Scheduler...seems easier to me, because in that case, you can schedule specific carts as needed... |
Greetings, |
Add the ability to link a cart to another cart.
The text was updated successfully, but these errors were encountered: