OK, we’ve already debated this somewhat in a nearby topic.
This request will depend upon working Envelopes (an announced upcoming feature) for its implementation. SO … let’s assume Envelopes are working, and proceed on that basis.
What I propose is a relatively simple Segue Editor (I vote for that as the best name), which allows visual editing and audio preview (cf. PFL player) of envelopes/fade times/anything else affecting the ‘join’ between two adjacent Items in a Playlist.
There would be a ‘global’ editor in Configuration, which would allow the creation/editing/deletion/selection of an unlimited number of user-named Segue Settings (maybe Tight, Blend, Slow Crossfade, etc.), as well as the editing (NOT deletion!) of a built-in Segue Setting named Default. Note that this function would require TWO demo audio files instead of the present one file shipped as part of the mAirList distribution. Ideally, the dialog would also allow the user to select the pre- and post- audio files via (for example) a pair of text boxes and associated Browse… buttons.
Segue Settings would be stored as well-formed XML stored in files with the MSS extension (mAirList Segue Settings); the file name being the user-defined Segue Setting Name (or Default). For example: Tight.mss, Default.mss, etc.
Playlist Items would also have a new context menu (right-click menu) item to access the Segue Settings editor, or perhaps access would be via a new tab in the PFL Player dialog; or even both. The Item Segue Editor would duplicate the functionality of the Global Segue Editor in Configuration, allowing the user to select (open) an existing MSS file, create a new segue from scratch or by editing an existing Segue Setting, or save a new Segue Setting for later use. The only disabled functions in the Playlist Item instance of the Segue Editor dialog would be Delete Settings (!), and the ability to select the two audio files (!).
‘Individual’ Playlist Item Segue Settings would be stored at Playlist level, i.e. in the MLP file if the Playlist is saved; and restored if the Playlist is inserted/appended/loaded into a running Playlist.
Some of the settings altered by a Segue Editor already exist: StartNext point, FadeOut point, etc. The principal ‘new’ data would be the Envelope settings, which would be used to set up talkunder/talkover. Hence the principal function of the Segue Editor would be to ‘visualise’ all these settings in a way that the user can easily interact with.
(Phew! Quite a while since I’ve written a semi-formal program spec.!)
We can debate that functionality/implementation as we go along, but I think that in this thread, we should principally consider how a Segue Editor would look and operate in practice. I’m certain Torben will let us know what, if anything, is either impossible or at least enormously complex to implement!
The SAM and Dalet editors are a good starting point; personally I like the ‘stacked’ look of the track graphics in the Dalet In-Flight Editor dialog, but prefer the general ‘feel’ of the SAM Crossfading dialog. I’ll give this some thought and will post a mock-up graphic at some point of how I think a mAirList Segue Editor should look IMHO.
SO, over to everyone else! Does all the above make sense? Have I missed anything by way of features, data storage, etc.? Does this sound like the right way to go in general? What do YOU think?
Let’s discuss … ! ;D
BFN
CAD