Hook and Loop button behaviour

I’ve asked my many friends who use pro-grade media playout hardware (e.g pro CD decks), and to a man/woman they all agree that both Hook and Loop should by default be ‘one shot;’ in other words, when selected, they should both by default reset to OFF once the current item hits EOF and/or when the Player Closes.

If you do want to ‘lock’ either Hook or Loop, again they all agree that a) to do this, you click AND HOLD the Hook or Loop button for three seconds before releasing the button; and b) you indicate ‘Hook lock’ and/or ‘Loop lock’ by flashing the buttons’ background colour. Clicking a flashing Hook/Loop button switches it off AND releases the ‘lock,’ so the button is again ‘one-shot’ when clicked normally.

A corollary of this is that Automation Play also ‘unlocks’ both Hook and Loop in all Players in that Playlist except perhaps ‘special’ Players (think about it!).

On a related topic, I would love to be able to store ‘play this Item looped’ and/or ‘play this as a Hook’ in both MLPs and MLCs (especially the latter, where I think the Hook and Loop status of each Player should ALWAYS be saved, as CartSlot\PlayerState\Hook {on|off} and CartSlot\PlayerState\Loop {on|off}, respectively). Another infinitely extensible XML extension where the framework will cope no matter how many Player toggle states you need to keep track of.

Also in my ideal world ;D, Cartwall Players are a special case. With the States saved in each CartSlot in an MLC file, loading a CartSet will automagically set each Cartwall Player to the correct state. Again, think about it: you create a Cart Set for (say) a contest with music beds, stings etc. and some Carts need Loop set. How excellent would it be to have that all your hard setup work saved statefully in your MLC and have it correctly restored when you load that MLC again later?! So for Cartwall Players, a Loop or Hook behaves exactly as at present, EXCEPT that the Hook and Loop states of ALL Cartwall Players are set at MLC load time.


Ok, so we need a few more options:

  • Reset Hook Mode on closing player.
  • Reset Loop Mode on closing player.
  • Save Hook Mode to cart set.
  • Save Loop Mode to cart set.

On the subject of hooks, is there any way we could introduce 2 or 3 different styles of containers.

I really love the feature of how it puts in sound FX between each hook but sometimes the hooks of songs may be slowies and so a ripping sound for dance tracks isnt suitable. therefore, the way to do this is to have create hook container and then a drop down box with container 1/2/3, each of which use a different set of FX for the different styles of hooks.

Hope this makes sense


Torben I rarely need to correct your normally excellent English (and my German is ‘nicht gut!’), but:

‘Reset … Mode on closing player’ should read ‘Switch off … Mode when Player closes.’


‘Save … Mode to cart set’ should read ‘Save … Mode in cart set (MLC) files’

Can I suggest a third option related to the second one?
‘Set Cartwall Player Modes from file data when opening cart set (MLC) files’
I think this is needed because people who don’t use the ‘Save Mode in MLC’ option can then be sure that opening an MLC will never set Cartwall Player Modes, even if the MLC file for some reason contains them.


I disagree with your last suggestion. mAirList should restore anything found in the MLC files. This is the same behavior as found when saving/loading desktop (MLD) files: They might contain the browsers, event list and cartwall, depending on your settings. But in case they do, these things will always be restored.

Technically, I only apply a filter to the XML output, but not to the input. Much easier for me, less options to pass around :wink:

I don’t think this is a major problem. Why should a cart set contain hooks when you switched that option off? And if it does, blame the person who saved the cart set with wrong mAirList settings. Not the developer :wink:


PS: Thanks for the English lesson :wink:

Any thoughts on my idea of having more than one option for choosing the FX for hooks?

It’s one of those needs-a-little-work-and-time things :wink:

Torben, I accept your point about restoring everything in an MLC file.

Yes, sounds like a good one and I’m sure Torben agrees. As he said, some things take longer to implement than others!


… in particular those which need time-consuming adjustments of the config dialog :wink: