Recent changes to Home

Home modified by Bert Mueller

Bert Mueller — Sun, 16 Jul 2023 17:30:25 -0000

--- v34
+++ v35
@@ -43,7 +43,22 @@
 In addition SMF Meta-Text-Event 0x9 is supported as well for name based port selection, however it is recommented to use device IDs rather than port names for better across system portability.

 ### midi recording
-The player generally supports live session smf recording from the primary midi input port. In addition, the software can also record individually selected events directly from the smf input file while playing. This provides a merged output smf storing mixed internal and external recorded data for further offline processing such as live + style smf down-mixing. Recorded data will be stored into a smf named MyMid*RecordTimeStamp*.mid within the current working directory. That way you can record as many takes as required without deleting older ones for further processing.
+The player generally supports full live session recording and captures all data across all sources such as smf-, primary- and secondary inputs at once. This provides a merged smf output for either further offline processing or manual editing and inspection in any sequencer software. The output smf structure is organized in track groups and tracks for each individual data source and their functional split groups. This includes the following output tracks:
+
+ - "conductor" track - contains general SMF setup data such as Tempo, KeySig, TimeSig, etc. and Marker Labels for each individual Label transition. Together with the primary chord track, you can easily follow chord changes respective their triggered sequence transitions.
+ - "SMF*" tracks contain all input SMF data in the same track structure and order as provided by the input SMF
+ - "Primary" - contains all remaining events which are not part of the primary key zones below (mainly all non-key channel, SysEx and system or realtime data)
+ - "Pri-Var" - variation key zone
+ - "Pri-Mute" - single mute key zone
+ - "Pri-Mutes" - mute-set key zone
+ - "Pri-Chord" - chord key zone
+ - "Pri-Other" - all other key events which are not part of the key zones above
+ - "Zone*" - track(s) w/ midi thru data as defined by the zonal key setup per individual thru zone
+ - "Secondary*" - track(s) w/ non-channel data from Seondary input port(s) while channel data get mixed directly into corresponding SMF tracks
+
+
+
+Recorded data will be stored into a smf named MyMid*RecordTimeStamp*.mid within the current working directory. That way you can record as many takes as required without deleting older ones for further processing.

 Recording is controlled by command line parameter #8 (0x0ff = off, else enabled). In addition, the parameter controls internal smf recording using a message mask filter scheme in the following binary/hexadecimal format:

@@ -55,11 +70,13 @@
    e: disable/enable event playing (allows to record internal events w/o playing them)

 example argument settings (hex values):
-- 0x1 - record only primary input events
-- 0x7ff040b0 - primary input + internal damper pedal events across all channels w/o playing them
-- 0x7ff0c0b0 - primary input + internal damper pedal events across all channels
-- 0x7fff06ff - primary input + internal marker text events (record meta events)
-- 0xff80f0 - primary input + internal sysex events (maybe used use for sysex data/dump requests)
+- 0x0ff - recording off
+- 0x8000 - record all events across all input sources
+- 0x1 - record only external primary input events
+- 0x7ff040b0 - external input + internal damper pedal events across all channels w/o playing them
+- 0x7ff0c0b0 - external input + internal damper pedal events across all channels
+- 0x7fff06ff - external input + internal marker text events (record meta events)
+- 0xff80f0 - external input + internal sysex events (might be used for sysex data/dump requests)

 ### supported midi event types (playing, recording)
 Basically all types of midi events including system common (sysex, time code, song select/position, etc.) and system realtime (start, stop, continue, active sensing) events are supported. Since system common (except sysex) and realtime events are not part of the smf specification, they are typically embedded in escape meta events (0xf7). Since the player generally supports such smf events, it is possible to include for instance time code, active sensing or start/stop/continue transport control events into the song sequence for playback.

Home modified by Bert Mueller

Bert Mueller — Fri, 28 May 2021 16:07:38 -0000

--- v33
+++ v34
@@ -49,10 +49,10 @@

    binary format: 0b_0mmmmmmm_MMMMMMMM_e_fffffff_FFFFFFFF
    0mmmmmmm: data mask (7 bit)
-    MMMMMMMM: status mask (8 bit)
-    0fffffff: data filter (7 bit)
-    FFFFFFFF: status filter (8 bit)
-    e: disable/enable event playing (allows to record internal events w/o playing them)
+   MMMMMMMM: status mask (8 bit)
+   0fffffff: data filter (7 bit)
+   FFFFFFFF: status filter (8 bit)
+   e: disable/enable event playing (allows to record internal events w/o playing them)

 example argument settings (hex values):
 - 0x1 - record only primary input events
@@ -104,7 +104,9 @@
 Interrupts are basically breaks stopping the current midi flow by jumping to defined target address labels. They are typically requested by external MIDI (NoteOn/Off) events either directly by single keys or thru the chord recognition module. Since both NoteOn and -Off events can request individual interrupts with different target address labels, its possible to trigger different sequences by either pressing keys down or releasing them.

 Interrupt vectors (target Labels in binary / hexadecimal notation):
-    
+
+
+
     general binary vector structure: 0bvvvvttttUiiirrrr
      vvvv:variation
      tttt:key/chord-type
@@ -115,12 +117,17 @@
       0x4:sus2 triad
       0x5:diminished triad
       0x6:augmented triad
-      0x7..0xe: unused (reserved for extensions)
+      0x7:maj7
+      0x8:m7
+      0x9:7
+      0xa:mmaj7
+      0xb..0xe: unused (reserved for extensions)
       0xf:internally used for auto-labels
      U: 0:key down; 1: key up
      iii:inversion (0: root down)
      rrrr:root (0x0..0xb; C..B)

+    #decoded value examples
     0x000..0x07f single key pressed down w/o chord recognition
     0x100..0x10b 5th root C..B no inversion
     0x110..0x11b 5th root C..B inverted
@@ -139,10 +146,10 @@

    binary format: 0b_0mmmmmmm_MMMMMMMM_e_fffffff_FFFFFFFF
    0mmmmmmm: data mask (7 bit)
-    MMMMMMMM: status mask (8 bit)
-    0fffffff: data filter (7 bit)
-    FFFFFFFF: status filter (8 bit)
-    e: disable/enable event playing (0: use event only for interrupt sync w/o playing)
+   MMMMMMMM: status mask (8 bit)
+   0fffffff: data filter (7 bit)
+   FFFFFFFF: status filter (8 bit)
+   e: disable/enable event playing (0: use event only for interrupt sync w/o playing)

 example argument settings (hex values):
 - 0x00008000 - trigger on all events (used for regular smf playing)
@@ -246,7 +253,7 @@
  - incoming channel messages including controller, pitch-bend, program-change, etc. are generally routed to active zones/tracks only. this allows to change selectively patches, volumes, pannings, etc. for active zones only while playing
  - exceptions are foot/pedal controller such as soft, sostenuto and sustain which are generally sent across all defined zones/tracks simultaneously
  - tracks can get dynamically re-assigned while playing by changing the incoming midi channel. to enable this option, `<channel>` needs to be <= -2. in this case, the received channel is added to the target tracks.
- 
+
 #### port/device mapping
 If the smf contains port-select meta-events where port numbers doesnt match to target device-IDs, you can apply additional port->device mappings.
 - `<0x0001ppDD>` maps smf-port `<pp>` to device ``
</pp></channel>

Home modified by Bert Mueller

Bert Mueller — Thu, 05 Nov 2020 20:20:04 -0000

--- v32
+++ v33
@@ -19,31 +19,19 @@

 [![](https://img.youtube.com/vi/xDB1_mUJekQ/0.jpg) example video link](https://www.youtube.com/watch?v=xDB1_mUJekQ)

-https://www.youtube.com/watch?v=jLzvZD7qkvo
-
-https://www.youtube.com/watch?v=Ahbt5QPF_tg
-
-https://www.youtube.com/watch?v=2qpwCve10z4
-
-https://www.youtube.com/watch?v=E8uwvp4kxnw
-
-https://www.youtube.com/watch?v=7zThYNON17g
-
-https://www.youtube.com/watch?v=8Hd0g54biWc
-
-https://www.youtube.com/watch?v=E4mxh2Or7OE
-
-https://www.youtube.com/watch?v=uI2Kjw_qcV4
-
-https://www.youtube.com/watch?v=TR1069JXejM
-
-https://www.youtube.com/watch?v=soGtmCMgepA
-
-https://www.youtube.com/watch?v=w0LiKwODiIE
-
-https://www.youtube.com/watch?v=5WDd0XAmTrY
-
-https://www.youtube.com/watch?v=3SKOt4oED8Y
+[example video link](https://www.youtube.com/watch?v=jLzvZD7qkvo)
+[example video link](https://www.youtube.com/watch?v=Ahbt5QPF_tg)
+[example video link](https://www.youtube.com/watch?v=2qpwCve10z4)
+[example video link](https://www.youtube.com/watch?v=E8uwvp4kxnw)
+[example video link](https://www.youtube.com/watch?v=7zThYNON17g)
+[example video link](https://www.youtube.com/watch?v=8Hd0g54biWc)
+[example video link](https://www.youtube.com/watch?v=E4mxh2Or7OE)
+[example video link](https://www.youtube.com/watch?v=uI2Kjw_qcV4)
+[example video link](https://www.youtube.com/watch?v=TR1069JXejM)
+[example video link](https://www.youtube.com/watch?v=soGtmCMgepA)
+[example video link](https://www.youtube.com/watch?v=w0LiKwODiIE)
+[example video link](https://www.youtube.com/watch?v=5WDd0XAmTrY)
+[example video link](https://www.youtube.com/watch?v=3SKOt4oED8Y)

 ### console output screen
 Generally there is not much to display since the user should more focus on playing and listen rather than watching the screen. However in some situations it comes handy to track and follow requested sequence transitions. Therefore the console output displays one line for each transition request with additional information such as labels and song/sequence positions for playing and target sequences.

Home modified by Bert Mueller

Bert Mueller — Thu, 05 Nov 2020 20:13:54 -0000

--- v31
+++ v32
@@ -18,6 +18,32 @@
 The style examples are typically setup with chord recognition left hand across 2 octaves thru keys 36..59 and melody right hand thru keys above 60 (middle C). If required, adjust the transmission midi channel on your primary input device in order to attach to the right smf tracks while playing.

 [![](https://img.youtube.com/vi/xDB1_mUJekQ/0.jpg) example video link](https://www.youtube.com/watch?v=xDB1_mUJekQ)
+
+https://www.youtube.com/watch?v=jLzvZD7qkvo
+
+https://www.youtube.com/watch?v=Ahbt5QPF_tg
+
+https://www.youtube.com/watch?v=2qpwCve10z4
+
+https://www.youtube.com/watch?v=E8uwvp4kxnw
+
+https://www.youtube.com/watch?v=7zThYNON17g
+
+https://www.youtube.com/watch?v=8Hd0g54biWc
+
+https://www.youtube.com/watch?v=E4mxh2Or7OE
+
+https://www.youtube.com/watch?v=uI2Kjw_qcV4
+
+https://www.youtube.com/watch?v=TR1069JXejM
+
+https://www.youtube.com/watch?v=soGtmCMgepA
+
+https://www.youtube.com/watch?v=w0LiKwODiIE
+
+https://www.youtube.com/watch?v=5WDd0XAmTrY
+
+https://www.youtube.com/watch?v=3SKOt4oED8Y

 ### console output screen
 Generally there is not much to display since the user should more focus on playing and listen rather than watching the screen. However in some situations it comes handy to track and follow requested sequence transitions. Therefore the console output displays one line for each transition request with additional information such as labels and song/sequence positions for playing and target sequences.

Home modified by Bert Mueller

Bert Mueller — Fri, 30 Oct 2020 16:31:58 -0000

--- v30
+++ v31
@@ -16,6 +16,8 @@
 In case you dont know your midi device IDs or names for the correct player setup, run MidiPorts.bat to list all input and output devices respective their IDs. Chose the right ones as primary input and output devices and adjust command line parameters #3 and #4 accordingly.

 The style examples are typically setup with chord recognition left hand across 2 octaves thru keys 36..59 and melody right hand thru keys above 60 (middle C). If required, adjust the transmission midi channel on your primary input device in order to attach to the right smf tracks while playing.
+
+[![](https://img.youtube.com/vi/xDB1_mUJekQ/0.jpg) example video link](https://www.youtube.com/watch?v=xDB1_mUJekQ)

 ### console output screen
 Generally there is not much to display since the user should more focus on playing and listen rather than watching the screen. However in some situations it comes handy to track and follow requested sequence transitions. Therefore the console output displays one line for each transition request with additional information such as labels and song/sequence positions for playing and target sequences.

Home modified by Bert Mueller

Bert Mueller — Tue, 20 Oct 2020 17:39:48 -0000

--- v29
+++ v30
@@ -173,7 +173,8 @@
 The player exits with different return codes based on the exit scenario.

 * 0 regular exit: the player normally reached the sequence end
-* 2 error: the player stopped due to timeout (lost midi equipment connection)
+* 1 error: e.g. file not found or argument error
+* 2 timeout: the player stopped due to midi timeout (lost midi equipment connection)
 * 3 CTRL+PAUSE/BREAK: player was forced to exit from computer keyboard
 * 4 exit: the player was forced to exit from primary midi input (exit label key)
 * 5 last: the player stopped normally after reaching the last sequence label

Home modified by Bert Mueller

Bert Mueller — Sat, 17 Oct 2020 16:58:54 -0000

--- v28
+++ v29
@@ -1,4 +1,3 @@
-
 # playsmf
 If you have additional questions, remarks, comments, ideas, requests - contact bm3_2000@yahoo.com

@@ -6,7 +5,7 @@

 

-In addition it comes with intrinsic flow control features based on labels, jumps and interrupts defined by smf marker events. This allows to program loops, breaks, fills, intros, outros, etc. In combination with realtime interrupt (sequence transition) control, based on incoming midi data with or without chord recognition, the player can turn into an fully equipped arranger/arpeggiator accompaniement software. However unlike typical arpeggiators or style players, the player doesnt do any (more or less intelligent) event data modification such as transpose, volume adjustments, etc. to the smf midi data and plays strongly the raw data exactly as provided by the smf. This gives full transparency to all transmitted midi data and you know exacly what gets played with each individual chord, however the smf needs to provide individual pattern for all required key/scale/inversion combinations which are played during a live session. Therefore its possible to play individual pre-compiled pattern - for instance with randomized timings/volume/controller/sysex events - for each individual chord.
+In addition it comes with intrinsic flow control features based on labels, jumps and interrupts defined by smf marker events. This allows to program loops, breaks, fills, intros, outros, etc. In combination with realtime interrupt (song sequence transition) control, based on incoming midi data with or without chord recognition, the player can turn into an fully equipped arranger/arpeggiator accompaniement software. However unlike typical arpeggiators or style players, the player doesnt do any (more or less intelligent) event data modification such as transpose, volume adjustments, etc. to the smf midi data and plays strongly the raw data exactly as provided by the smf. This gives full transparency to all transmitted midi data and you know exacly what gets played with each individual chord, however the smf needs to provide individual pattern for all required key/scale/inversion combinations which are played during a live session. Therefore its possible to play individual pre-compiled pattern - for instance with randomized timings/volume/controller/sysex events - for each individual chord.
 On purpose, the player lags for a graphical user interface since everything should be controlled in realtime by external MIDI equipment without taking your hands off the keyboard while playing. This includes direct access to style variations, grouped track mutes/unmutes, start/stop/continue/reset control, etc.

 
@@ -24,7 +23,7 @@
 

 ### output MIDI devices
-The player generally allows to play across multiple output devices simultaneously. Typically devices are chosen by SMF Meta-Event 0x20 (port select) for each individual track. Since the player uses those messages to switch beween output devices accordingly, it is valid to switch devices while playing within a sequence. If such port-select events are missing, the player uses the default midi output device.
+The player generally allows to play across multiple output devices simultaneously. Typically devices are chosen by SMF Meta-Event 0x20 (port ID select) at the very beginning of each individual track, but in addition the player also allows switching port IDs while playing at any song position. If port-select events are missing, the player uses the default midi output device provided by command line parameter #3.
 In addition SMF Meta-Text-Event 0x9 is supported as well for name based port selection, however it is recommented to use device IDs rather than port names for better across system portability.

 ### midi recording
@@ -43,8 +42,13 @@
 - 0x1 - record only primary input events
 - 0x7ff040b0 - primary input + internal damper pedal events across all channels w/o playing them
 - 0x7ff0c0b0 - primary input + internal damper pedal events across all channels
-- 0xff06ff - primary input + internal marker text events (record meta events)
+- 0x7fff06ff - primary input + internal marker text events (record meta events)
 - 0xff80f0 - primary input + internal sysex events (maybe used use for sysex data/dump requests)
+
+### supported midi event types (playing, recording)
+Basically all types of midi events including system common (sysex, time code, song select/position, etc.) and system realtime (start, stop, continue, active sensing) events are supported. Since system common (except sysex) and realtime events are not part of the smf specification, they are typically embedded in escape meta events (0xf7). Since the player generally supports such smf events, it is possible to include for instance time code, active sensing or start/stop/continue transport control events into the song sequence for playback.
+
+On the recording side, the player records everything including sysex, system common and system realtime events except midi timecode, timing clock and active sensing. Similar as on the player side, the recorder packs system common and realtime events (which are not part of the smf spec.) into escape meta events. This way you can even record something like start/stop/continue transport control data into the smf.

 ### MIDI-Thru and track-follow mode
 The player generally supports MIDI-Thru functionality with split and multi-layer modes for live sessions. However instead assigning fixed devices/channels to play on, you can assign tracks to follow their current device/channel combinations while playing. This enables dynamic MIDI-Thru (re)assignments during a live session.

Home modified by Bert Mueller

Bert Mueller — Fri, 16 Oct 2020 21:04:45 -0000

--- v27
+++ v28
@@ -32,11 +32,11 @@

 Recording is controlled by command line parameter #8 (0x0ff = off, else enabled). In addition, the parameter controls internal smf recording using a message mask filter scheme in the following binary/hexadecimal format:

-   binary format: 0b_0mmmmmmm_MMMMMMMM_e_vvvvvvv_VVVVVVVV
+   binary format: 0b_0mmmmmmm_MMMMMMMM_e_fffffff_FFFFFFFF
    0mmmmmmm: data mask (7 bit)
-    FFFFFFFF: status mask (8 bit)
-    0vvvvvvv: data filter (7 bit)
-    VVVVVVVV: status filter (8 bit)
+    MMMMMMMM: status mask (8 bit)
+    0fffffff: data filter (7 bit)
+    FFFFFFFF: status filter (8 bit)
     e: disable/enable event playing (allows to record internal events w/o playing them)

 example argument settings (hex values):
@@ -117,11 +117,11 @@

 Interrupts are controlled by command line parameter #9 (0x0ff = off, else enabled) using a similar event mask filter scheme as used for recording in the following binary/hexadecimal format:

-   binary format: 0b_0mmmmmmm_MMMMMMMM_e_vvvvvvv_VVVVVVVV
+   binary format: 0b_0mmmmmmm_MMMMMMMM_e_fffffff_FFFFFFFF
    0mmmmmmm: data mask (7 bit)
-    FFFFFFFF: status mask (8 bit)
-    0vvvvvvv: data filter (7 bit)
-    VVVVVVVV: status filter (8 bit)
+    MMMMMMMM: status mask (8 bit)
+    0fffffff: data filter (7 bit)
+    FFFFFFFF: status filter (8 bit)
     e: disable/enable event playing (0: use event only for interrupt sync w/o playing)

 example argument settings (hex values):

Home modified by Bert Mueller

Bert Mueller — Fri, 16 Oct 2020 15:55:25 -0000

--- v26
+++ v27
@@ -1,3 +1,4 @@
+
 # playsmf
 If you have additional questions, remarks, comments, ideas, requests - contact bm3_2000@yahoo.com

@@ -25,6 +26,25 @@
 ### output MIDI devices
 The player generally allows to play across multiple output devices simultaneously. Typically devices are chosen by SMF Meta-Event 0x20 (port select) for each individual track. Since the player uses those messages to switch beween output devices accordingly, it is valid to switch devices while playing within a sequence. If such port-select events are missing, the player uses the default midi output device.
 In addition SMF Meta-Text-Event 0x9 is supported as well for name based port selection, however it is recommented to use device IDs rather than port names for better across system portability.
+
+### midi recording
+The player generally supports live session smf recording from the primary midi input port. In addition, the software can also record individually selected events directly from the smf input file while playing. This provides a merged output smf storing mixed internal and external recorded data for further offline processing such as live + style smf down-mixing. Recorded data will be stored into a smf named MyMid*RecordTimeStamp*.mid within the current working directory. That way you can record as many takes as required without deleting older ones for further processing.
+
+Recording is controlled by command line parameter #8 (0x0ff = off, else enabled). In addition, the parameter controls internal smf recording using a message mask filter scheme in the following binary/hexadecimal format:
+
+   binary format: 0b_0mmmmmmm_MMMMMMMM_e_vvvvvvv_VVVVVVVV
+   0mmmmmmm: data mask (7 bit)
+    FFFFFFFF: status mask (8 bit)
+    0vvvvvvv: data filter (7 bit)
+    VVVVVVVV: status filter (8 bit)
+    e: disable/enable event playing (allows to record internal events w/o playing them)
+
+example argument settings (hex values):
+- 0x1 - record only primary input events
+- 0x7ff040b0 - primary input + internal damper pedal events across all channels w/o playing them
+- 0x7ff0c0b0 - primary input + internal damper pedal events across all channels
+- 0xff06ff - primary input + internal marker text events (record meta events)
+- 0xff80f0 - primary input + internal sysex events (maybe used use for sysex data/dump requests)

 ### MIDI-Thru and track-follow mode
 The player generally supports MIDI-Thru functionality with split and multi-layer modes for live sessions. However instead assigning fixed devices/channels to play on, you can assign tracks to follow their current device/channel combinations while playing. This enables dynamic MIDI-Thru (re)assignments during a live session.
@@ -93,7 +113,22 @@
     0x320..0x32b minor triad root C..B 2nd inversion

 ### Interrupt sequence flow transition syncronisation
-In order to guarantee smooth sequence flow transitions, interrupts are only taken at either jump points or certain defined midi events within the sequence. For example those can be metronome click NoteOn messages or specific controller or meta events. This approach makes syncronisation completely independent from fixed time signatures in terms of bars and beats and refers only to so called ***INT*** points - basically sequence points where interrupt transtions are allowed.
+In order to guarantee smooth song sequence flow transitions, interrupts are only taken at either jump marker positions or certain user-defined midi events such as metronome clicks, controller data, meta events, etc. within the song sequence. This approach decouples interrupt syncronisation completely from fixed time signatures or grids in terms of bars, beats, ticks and refers only to so called interrupt (***INT***) positions - basically song positions where interrupt transtions are allowed.
+
+Interrupts are controlled by command line parameter #9 (0x0ff = off, else enabled) using a similar event mask filter scheme as used for recording in the following binary/hexadecimal format:
+
+   binary format: 0b_0mmmmmmm_MMMMMMMM_e_vvvvvvv_VVVVVVVV
+   0mmmmmmm: data mask (7 bit)
+    FFFFFFFF: status mask (8 bit)
+    0vvvvvvv: data filter (7 bit)
+    VVVVVVVV: status filter (8 bit)
+    e: disable/enable event playing (0: use event only for interrupt sync w/o playing)
+
+example argument settings (hex values):
+- 0x00008000 - trigger on all events (used for regular smf playing)
+- 0x7fefa189 - trigger on NoteOn events from channel 9, key 0x21 (metronome klick - e.g. use for styles)
+
+Please note that interrupts are still triggered on Jump position markers even though the interrupt argument might be turned off (0x0ff).

 ### Special Jumps - return from interrupt (Jump-1/Jump-3)
 One specific jump type is ***return-from-interrupt***. Actually there are two basic types of sequences: "non-return" (e.g. ending in a infinite loop) or "return" ending with an "return-from-interrupt" jump. Return-type sequences terminate with an immediate jump back to the caller sequence bei either restarting the caller sequence from its interrupt entry point (Jump-1) or from the latest label playing when interrupted (Jump-3).

Home modified by Bert Mueller

Bert Mueller — Wed, 14 Oct 2020 15:19:11 -0000

--- v25
+++ v26
@@ -18,7 +18,7 @@
 The style examples are typically setup with chord recognition left hand across 2 octaves thru keys 36..59 and melody right hand thru keys above 60 (middle C). If required, adjust the transmission midi channel on your primary input device in order to attach to the right smf tracks while playing.

 ### console output screen
-Generally there is not much to display since the user should more focus on playing and listen rather than watching the screen. However in some situations it comes handy to track and follow requested sequence transitions. Therefore the console output displays one line for each transition request with additional information such as label and song/sequence position currently playing- and the requested target label song position.
+Generally there is not much to display since the user should more focus on playing and listen rather than watching the screen. However in some situations it comes handy to track and follow requested sequence transitions. Therefore the console output displays one line for each transition request with additional information such as labels and song/sequence positions for playing and target sequences.