We have mix files in which we added extra cue markers to know which songs are in these mixes. But how do I get a trigger of these cue markers in a script (something like OnItemStart but then OnMarker?) and how do I read out the fields that we have put in there?
Same question for logging, what is the syntax to log these fields?
What you enter in these markers as artist/title is simply processed by the logging subsystem, in the same way as the regular items are logged. No need to configure something special here. As far as I know, OnItemStart should also be triggered (with a temporary item constructed from the information you entered).
As for access to these markers from a script (for manipulation etc.): GetCuePosition is for the plain cue markers (Cue In, Ramp, etc.). GetCueData is what you are looking for, which gives access to the list of “additional” cue markers
Thanks Torben and Happy New Year to you and everybody here too!!
I figured this out in the meanwhile and does the job perfectly for us.
I found some other thing that may be adjusted in a future version. When exporting a mixdown, if you select to save a cue sheet these track markers are not included, which is pity because we want to make a podcast from a certain mix program and add the cue to Mixcloud.
Thinking about this, perhaps the wrong place to ask because it doesn’t have much to do with the original post, but: is there a way to automatically make a mixdown from a script or something?
Wow great! Just tried it out and works perfectly, thanks!
Would be very nice if exporting a cue sheet from a script mixdown would also be possible.
I found a small bug in the track marker system. We just started our mixed shows now and see that when the first marker is set at 00:00:00, so the very beginning of the track, it is ignored, but instead the actual information of the item itself is logged. I think this should be the other way around. In most cases I would think that the content you put in the artist and title field of such files is only for internal use and it’s the track markers you want in logging (website playlist, RDS, icecast, etc.). Is this also something you can fix easily?
This brings me to another suggestion for the cue points dialog. It would be very nice if you could just search for items from the database there. For example most of the songs we use in our mixes are also included in our database, so if we could search for an item there (like for example you search for an item when defining a specific item in an hour template), the system could just link that marker to a database id and use all metadata from that item (artist, title, external id, attributes). You could replace the “id” field with such a search field. In case it’s an item you don’t have in your db you can always manually fill in the artist and title…
Also, I would suggest adding and extra field there “item type” where you can adjust the item type for that marker instead of using the one defined in the parent db item. For example if you haves mixes and set the item type to “package” like we do now, and set all track markers to item type “music”, you can easily avoid any internal things in logging. Perhaps it would also be the best solution to the bug in the third paragraph because you can then by default log both, and always choose which item types you want in your logging. Another idea would be to add an extra item type “track marker”, would also be useful since I think at this point there is no way of distinguishing a track marker from a real item.
Stuff to think about, and all suggestions and ideas from other users are welcome of course!
Thinking about this again… Generally I think the best solution would be to use the type system (but that requires a type field for the cue markers, not currently there). Then you can just filter by type, and set the outer item to some random type which is not included in the type list for the cue sheet output.
For the moment, would it solve the problem if we just filtered the cue markers in a way that duplicate positions are ignored, and the the last position “wins” in case of duplicates? That would be relatively easy to achieve with the data structures I’m using internally.
No, the child item wins. This makes more sense to me, and it’s also what you ask for, isn’t it? See above:
This does not apply to logging, and I cannot implement it there, as it uses an entirely different mechanism (information is broadcasted in realtime, it cannot “look ahead”). Please wait for the type filter system.
Yes perfect, but that’s the same as I say just in other words
For the logging I can probably fix it by moving the first marker 1 second further, I’ll try that as a fix for now. Because now our RDS and stream displays strange things while the first song plays. Unfortunately by moving it away from the very beginning the problem with the mixdown is back again I think, but as long as they are all in there I can always remove the ones that I don’t need in the cue sheet manually for now.
Just did a mixdown of our next show. We have 3 files, with the first two the result was the same, so it used the artist and title of the parent item instead of the first marker, but then suddenly with the 3rd one it was correct… Very strange
That is wonderful! Is there somewhere an explanation on how to use MixdownPlaylistWithOptions?