Thanks Torsten! I most certainly will, and it sounds as if it ticks all my boxes!
Cheers,
John
Hopefully 
You’re probably right… but I was just thinking about trying to make the typical case simpler. For cases like you describe (long intros etc…) you could just create an extra cue point at the same scroll position to manually create a delay.
Brad
The cue points idea sounds really useful!
These sound like really excellent changes. I’ve been thinking about the ramifications of this over the weekend, and don’t see any disadvantages, but it’ll fix several quite limiting aspects of the current Show Notes implementation.
I only have two concerns really. The first is what would happen if you decide to reorganise song states significantly, and the risk of doing something unintended to the show notes scrolling order without the visibility to clearly see why.
Secondly, and possibly related to the above, is in ensuring it’s still simple to use for new Cantabile users. Conceptually it’s not hard, but I think getting the UI right could make a big difference.
To mitigate both, it might be good to ensure that the link between show note scrolling and states is quite clear and visible in the UI. Perhaps an indicator/list/something that’s always visible in the show notes view (except in Live Mode), so you can see which states will invoke each note. Similarly, when looking at song states in the states list, perhaps some indication that there’s a show note associated with it could be useful. And potentially being able to make an association from either a show note or a song state, not just from a show note.
I like the idea of being able to “dock” a note either to the top or bottom, regardless of how show notes are scrolled. I’d find that useful for some status type information I put into show notes (with variables) or song-wide reminders.
I was trying to think of a good reason to keep the hidden/visible option on show notes, but couldn’t come up with anything that wouldn’t be better done using the other proposed features. The only thing I wondered was how you’d support users who are already using show/hide - would you have a migration process that can set up the necessary associations?
If you step to a song state with no notes set to “Keep this note on screen in these states”, would the show notes just stay where they are?
One thing @Corky mentioned is that he changes his show notes colours, so that when he changes state, the colour change gives him feedback that the change occurred as planned. Would this still be possible in the new scheme? I’m wondering how it would work if show notes have a colour assigned, but also show notes that are scrolled into view by association with the new song state also get a colour assigned to differentiate them as the “current note” from the other notes. Perhaps the note that was scrolled into view by a state could get a border or something?
How would this work in conjunction with the show-note-driven scrolling above? If you used both mechanisms, would they just fight it out, scrolling at cue points and state changes? What would happen if a state change causes a scroll change, part way through auto-scrolling between cue points?
It also occurred to me that it could be really useful to have bindings to scroll forward/backwards through notes, for users for whom show notes aren’t easily associated with song states, and who aren’t playing along to a timeline. An example might be someone playing with sheet music images, where sound (state) changes might fall within a page (or not happen at all), so they want separate show notes control.
Neil
1 Like
I think the best for cue point management is not a absolute value in a song…
rather a relativ value to the previous cuepoint/Marker so you can jump to a cuepoint/Marker also from a state and it is no problem for the total songduration.
…so you could have one cohesively textPage for better overviewing and with timed Markers you could bind the site also to a state if you want. The programm could then calculate the scrollspeed automaticaly to the next cue/endsong…
also it would be no problem to jump back to a refrain to play it one more time or anything else…
Good ideas!
Yes I think the current visible/hidden would be mapped to keep visible/keep visible in this state. The transition probably wouldn’t be perfect for everyone but should be close for most common usages (I think).
Correct
Yeah I wondered about this too and either only apply the highlight to notes that have the “default” color selected or a different type of highlight - like you suggest, a border or something.
You’d only be able to use one approach per song. Probably a switch setting somewhere, or perhaps if there are any cue points the other mechanism’s gets disabled.
There are already bindings for this…
I should have looked! I’m not surprised
Neil
Some thoughts on ease of use. I have been thinking that most users that would scroll lyrics would find it easier to copy the entire raw text file into the show note edit window and from that edit window be able to mark areas of the text for recoloring and point size / justification. This would complicate the onboard text editor but to what extent I am not certain, It would probably require a rich text editing environment to be brought into it but only @brad could tell me if it made practical sense. It would certainly reduce the opening and closing of cells to edit things and streamline the highlighting of areas in the note with less running around.
On the way it gets programmed, it looks like it needs to have manual programming for sure but that could be a little complicated for a beginning user as @Neil_Durant pointed out. It opens the possibility to look at the problem from a users starting point of view when trying to employ it.
-
First they would get the notes together in text form to copy into the Show Notes edit window later on
-
Second they would add a note and paste the text content into the edit window and format the point size and justification and upon saving it they can adjust the colors for the whole notes cell (font and background)
-
Third they would audition and jog the transport timeline to the position you want to put a scroll position cue marker
-
Fourth they would scroll manually the show notes to the desired scroll position for that same cue
-
Fifth they would press the magic button that creates the marker/cue points and links the notes position to the timeline position
-
Sixth they set any delays or scroll speed values between the current marker and the next one
repeat step 3 thru 6 at each new marker you create till done
That sounds pretty complex to me except for the easy button part that creates the markers. So it looks to me like the places it could be simplified are the
-
edit note process itself (keep the font size, justification and colorization of fields managed inside the same note edit window). Indeed much like a rich text editor environment there instead of what we have now.
-
the creation of cue points, this is where there are a great many factors so simplifying it is harder. Most current Chordpro players have the same problems with scroll position so they use pause markers in the chordpro script combined with an adjustable scroll speed that you set with a slider and leave. It uses an algorithm to get it’s initial speed based on the tempo and the song length (also saved with the script)
Brad, I think is proposing a system like that, where the metronome settings + the length of the timeline track adjust the initial scroll speed. That is a good feature to have for sure. I think though that after pondering on it a few days a user would have to have a pretty good plan of how he wanted to view his cues and where on the scroll position that he would want markers. So it might be faster to do the tasks in 2 parts. First set all the scroll position markers, each of them held in a list for later use. Then the user would go to the time line and locate the timeline positions they wanted. As they located each one they could tie it to a scroll position marker in the list you already made. Then the scroll speed fine tuning adjustments between markers would be automatically calculated and applied to each marker to marker scroll speed. For most songs and users I think that would cover it. The use of delays definitely requires more user input. All these things take time so I have been weighing it against another idea.
Another way I have already devised is to play the timeline track back and record the keystrokes on the arrow cursors on the keyboard (that scroll the notes) to a MIDI track for playback to the scroll position bindings later in exact sync with the original timeline track you chose. There are no pauses to add because you are creating them during the recording of the “automation track”. No ramp speeds on the scrolling because you determine it manually as the track plays back. You can jpage or scroll up or down at any time as well if you need to jump back to a part. Cantabile might benefit from a silent dedicated automation track recorder of this sort for this purpose as well as other uses not yet brought out. It would need to work with any media player updates that are coming. Anyway, just more wood on the fire 
Dave
So much great insight here.
As always seems to happen with show notes the problem is bigger than I originally guessed and it always seems to come back to a
number of fundamental problems with the current show notes implementation.
As you probably know I’ve previously considered:
- replacing the show notes with markdown style formatting
- writing HTML parser/renderer to support the markdown
- including chord pro formatting support,
- introducing support for external text editors
- fancy markup to tag sections of the notes for different states
- and more (including the changes I’ve proposed above re auto scrolling).
It’s all a very messy, so I’m starting to come to the realisation that the best solution might be to simply bite the bullet and write a rich text editor so you can directly edit notes in the show notes window (as suggested by Dave above).
Obviously that’s a pretty big job and I don’t want to write an entire word processor but even a basic editor (I’m thinking something similar to what’s available in Medium’s document editor) is going to be way better than what’s currently supported.
I’m currently working on some other stuff, so I’m going to let it simmer in the background for a bit - but please continue to discuss it - eventually it will all seep in.
Essentially I want to avoid introducing more and more small changes to the current show notes each of which just makes the transition to a final better solution more painful. Bear with me 
2 Likes
Yes…I would hate to lose all my 600+ songs with several states of lyrics, chords, and song maps. It only took 2 yrs to set them up. 
1 Like
I was never happy with this approach - I wanted a more precise way of controlling scroll position and scroll speed in LivePrompter. LivePrompter uses the concept of “current line” and “screen focus”. The current line is the vertical position in the song the reader is currently following - it moves down the song file at varying speed. LivePrompter tries to keep the current line at a customizable vertical position, the “screen focus”. By default, this is at one-third from the top of the screen (since it is more useful to look ahead than to look back).
Of course, at the beginning of the song, the current line is above the screen focus, so LivePrompter won’t start scrolling until the current line has actually reached the screen focus. Same at the end of the song: LivePrompter scrolling will be reach the end before the timed end of the song, since the current line needs some time to travel down from the screen focus to the actual end of the song.
When there aren’t any more fine-grained cue points defined (see below), LivePrompter automatically calculates its scrolling speed from the length of the song display and the duration:xxx tag in the song file.
Now to the problem of wordy verses and compact guitar solos: To implement @dave_dore’s cue points, I use a (non-displaying) tag inside the song lyrics/chord files: {d_time:xxx} with xxx being the time in seconds when the "current line should be at the screen focus point.
When preparing a song, I use a simple Excel spreadsheet to calculate these seconds values and then enter them in the d_time tags - now LivePrompter knows exactly what scrolling speeds it needs to use while scrolling its current line between each of these tag locations.
Maybe this could be an easier way to set scroll position markers directly in the show notes than the two-phase approach? Plus, no need to fiddle with timeline positions…
Maybe even with a metronome scaling feature (change all tags automatically on master tempo change or set the calculation tempo in a tag ath the beginning of the notes and then adapt the tags on-the-fly based on current master tempo)?
Cheers,
Torsten
1 Like
Wow Torsten! Very nice. 
I too was unhappy with the SongBook stock scrolling features and I am very impressed by your proprietary approach you implement in your LivePrompter software @Torsten.
I like how well organized your method is so big thumbs up! A question I have is how do you gather the time data in your D column, don’t you have to review the media track used as the time map and then jot down the Intro, Chorus, Verse etc … times for use in the excel sheet as you move through it? I’m just getting a feel for how long it takes you to do an average song with all the media review and mapping and the eventual addition of the script markers in your modified Chordpro file.
Thanks,
Dave
Hi Torsten,
I installed LivePrompter this weekend. Was very easy to install and works fine on my Cantabile laptop. I setup ChordPro also and spent some time on directives and reading about the history of chordii.
Thanks for making it available!
What a nice approach @Torsten, I like it. Once you defined the song/chord structure and the master tempo and cantabile could calculate the scrolling tempo. Changing mastertempo causes new scrolling speed, so stick to the tap button when your not playing a backing track 
.
What about improvisation? double the guitarsolo to 20 bars on the fly for instance? Option 1: you can tap the tag (which in that case shouldn’t be hidden) and scrolling starts from that position again. Works only when using touch devices and when tags are on screen. Option 2 : Optionally bind a tag to song state, a knob etc…
Unless you are playing to a click track or using an audio background file, It is not going to be perfect anyway. I know no one who can keep a perfect tempo. It will always vary, and if the count off is slightly varied, then even more variances. If you happen to have a guitarist that decides to take a longer solo to impress a patron, it throws everything out of sync. What if you have people dancing, but the song is too short? Do you just say sorry and pull up another song? Many times I have lengthened a song because the people were having a great time, and I wouldn’t kill their fun. Tips matter!
Improvisation is meant to be unrestricted, and truthfully, the only way to allow for it on a scrolling text is to hit a switch to stop, and start the scroll.
Corky
What I usually do when I have variable segments in a song (“guitarist solos over 12 bar blues until he runs out of ideas”): I insert a “pause” tag in my song at an appropriate place. This automatically puts LivePrompter in pause mode, i.e. scrolling stops until I hit a key/pedal/button. So the free iterations aren’t included in the time calculations. Once the guitarist signals that he’s done with the solo, I simply hit a “play/pause/continue” button on my keyboard, and scrolling continues.
When we spontaneously decide to tack on another chorus, solo etc, I simply hit the same button, so it pauses scrolling. The “pause” tag simply automates this, so I don’t need to think about it. LivePrompter is all about concentrating on making music, not operating a teleprompter.
Cheers,
Torsten
1 Like
Yes, we play fully live as well, without a click or backing track. Our drummer uses the LivePrompter metronome display to get initial tempo and to check if he’s not completely running wild from adrenaline…
In my experience so far, I need two buttons/pedals to operate my scrolling: my main button is play/pause/continue - when we’re playing too slow (or adding another solo), I can simply pause scrolling for a while until we’ve caught up. Then I have a “forward” button, which scrolls the screen down by one third, for those occasions when we’re too fast compared to the original tempo so the prompter can’t keep up.
BTW: the LivePrompter “play/pause/continue” button can also be configured as a context-sensitive “universal key” so it also doubles as “next song” button when the song is scrolled to its end. So you can essentially operate LivePrompter with two buttons for a whole gig.
Sorry for all the LivePrompter marketing, but maybe these examples from my experience with building and running LivePromper can provide useful input for creating autoscrolling show notes in Cantabile.
Cheers,
Torsten
1 Like
Hey @dave_dore,
I don’t enter the D column, I simply enter the number of bars of each section in the B column; the spreadsheet takes care of calculating d_time and start time. Counting bars is pretty easy per se, but for most of our songs, I prepare a leadsheet in this format to hand out to band members who don’t use LivePrompter (shame…):
With this, it’s even easier to fill column B: simply count the boxes…
And yes, I tend to be a bit over-organized sometimes… 
Cheers,
Torsten
3 Likes
I had no doubt that you covered all the bases on Live Prompter. 
When I was using Set List Helper sometime back, I used the pause feature many times, but had to do that manually. I tried C3’s resident notes scroll and page down, and it works quite well. Unless there is someone under the stage running the scroll on a teleprompter (not gonna happen), I am acclimated to page changes with states, and color changes to verify change and position. I can go back to repeat a verse if needed, or skip ahead with a simple touch of a lower key on the controller. As I stated above, in my little world, pages are easier to follow than moving text, because my eyes are constantly moving away from the notes, and it is easier to lock back into place when glancing back.
I think it is absolutely great that you provide LP free to everyone, and I don’t believe anyone in this forum has a problem with your “marketing”; I certainly don’t. You do have the experience, and forethought after developing this exceptional program. I still plan to give it a go after my recent GAS attack is completed.
Regards
Corky
1 Like