Any Hook Fade cue point is ignored (in both AUTO and ASSIST modes). No fade happens :(.
Hook End is not working properly.
Using a Hook Container in ASSIST, the Player remains in a strange audio-is-stopped-but-Player-is-ON AIR mode at HOOK END and has to be STOPped manually.
Using a Hook Container in AUTO, the same happens, so effectively, automation is stopped!
Clicking Create Hook Container randomly (?) causes an Access Violation at 00580DEF. This almost always happens if the Playlist is empty; it sometimes happens when right-clicking a music track item in the Playlist as well.
It is possible to select a Hook Container, right-click it, and click Create Hook Container (!). I don’t think this is intentional? The Contents tab of the second Hook Container shows an item of Hook Container, duration 0:00.
If a Player has a Hook button displayed, and a Hook Container is loaded into it, the Player’s Hook button is not disabled (!). I don’t think it makes sense to have a Hook mode button showing in a Player containing a Hook Container!
I don’t think it should be possible to create a Hook Container for a track which has no Hook cue points defined. At minimum, I think a warning MessageBox should be displayed (This item has no Hook points defined, so the Hook Container will contain the entire track. Are you sure you want to do this? Yes/No).
–
BFN
CAD
Was reported by several other people, but I’m still not able to reproduce it here
Do you use any closer jingle? And, if so, does it have any Fade Out or Cue Out points set?
This morning, I stumbled upon some problems with the Popup Menu and the disabling of certain menu items when there’s no item selected or present. Should be fixed in v.42.
The Hook Container function does not care about the types of the underlying playlist items. It can be any kind of playable item mAirList supports: files, streams, silence, audimark, and also containers. This is the cool thing about containers: they just wrap a list of items of any type, and treats them as a single item. As the Hook Container is nothing more than an ordinary container (created by creating a copy of each song item, copying Hook In to Cue In etc., and adding the jingles), it can also be put into another container, and so on. Of course, there’s no deeper sense in creating a Hook Container of another Hook Container, but there’s also no sense in preventing it.
I repeat: A Hook Container is nothing but a simple container. And a container is a playable item just like any other item. You can even set Hook In etc. on the outer container item. So, in principle, it is possible to play a (Hook) container in Hook Mode. Sounds crazy, but once you get the basic idea behind these containers, it’s quite an ingenious, natural concept.
I believe each user will decide to use the hook feature in exactly one of the two approaches provided: Either by setting the player into hook mode, or by creating Hook Containers (which do not rely on the player hook mode at all, because they only use the ordinary Cue In, Fade Out, Cue Out points internally). So these two concepts will most likely never interfere with each other.
Oh dear :(. If it’s any help, I use a (German! ;)) Terratec EWX24/96 sound card and Windows XP. If I load a track into a Player and (in ASSIST mode) click HOOK then PLAY, the track plays from the hook start, the remain time hits zero at the Hook FADE point (and remains at -0.0!), and the track plays at full gain up to the hook end point. Then the track unloads from the Player.
No, I don’t use any jingles, just a single track. It looks like a similar problem to the Cartwall Player one where Cartwall Players ‘stuck’ in EOF mode, except that the Playlist Player is still in ON AIR mode with the hook container still loaded and the PLAY button lit even though the Player is stopped; and if AUTO is enabled, AutomationPlay is still ‘on’ BUT the next track in the Playlist never starts (!). I think this must be some kind of failure to update the Player GUI and no doubt some events not firing as a consqeuence (events would presumably unload the Player etc. in normal circumstances, at a guess? ;)).
Ah-HA! I notice that PFLing a Hook Container shows ALL Cue points in the ExtraPFL Player as blank/zero: is that intentional? If not, maybe that might help you find and fix the ‘no fade out’ problem?
One more hook-related bug for you: the HOOK button in a Player remains ON (pressed) after the Player is unloaded, and therefore it is still ‘on’ when another track is loaded into the Player. Presumably not what was intended? I would imagine that the HOOK button should only be ‘on’ for one track and Hook should always switch ‘off’ when the Player is unloaded/idle, yes?
Well, ok, that’s assist mode. Players never fade out by themselves in assist mode, unless you have set the respective player option. The behavior with Hook Fade (in hook mode) should be the same as with Fade Out (in non-hook mode).
In the original post, you’ve mentioned that it also happens in automation mode? Is that true? If so, this is really odd, because in automation, as you know, players always fade out by themselves.
The remain time shows 0:00 because you’ve probably enabled “regard Fade Out as EOF” (it’s a global option the Misc section in the config).
No, I don't use any jingles, just a single track. It looks like a similar problem to the Cartwall Player one where Cartwall Players 'stuck' in EOF mode, except that the Playlist Player is still in ON AIR mode with the hook container still loaded and the PLAY button lit even though the Player is stopped; and if AUTO is enabled, AutomationPlay is still 'on' BUT the next track in the Playlist never starts (!). I think this must be some kind of failure to update the Player GUI and no doubt some events not firing as a consqeuence (events would presumably unload the Player etc. in normal circumstances, at a guess? ;)).
I believe the problem is that the inner playlist item does not report its EOF (or Cue Out, or reaching End of Fade) properly to the container, so the container will never report its end to the player. So the player thinks that it is still playing, although playback has stopped already.
Ah-HA! I notice that PFLing a Hook Container shows ALL Cue points in the ExtraPFL Player as blank/zero: is that intentional? If not, maybe that might help you find and fix the 'no fade out' problem?
No, that’s ok. As mentioned above, the container can have its own set of cue points. The cue points of the inner items are hidden inside the container.
One more hook-related bug for you: the HOOK button in a Player remains ON (pressed) after the Player is unloaded, and therefore it is still 'on' when another track is loaded into the Player. Presumably not what was intended? I would imagine that the HOOK button should only be 'on' for one track and Hook should always switch 'off' when the Player is unloaded/idle, yes?
Not quite … what happens if you want to manually play a sequence of hooks from the same (auto-load) enabled player?
Yes it does, and yes it is, and yes they should. This looks identical to the problem you found with item not reporting correctly to its container: it behaves the exact same way. In this case, it’s the Player object that is plainly not receiving an ‘EOF’ message from the item being 'Hook’ed.
Um … I thought that was the purpose and function of a Hook Container? ;D Maybe this needs to be a new Config option for a Player (Set Hook Mode OFF at EOF)?
