I’ve started planning out some changes for show notes and while I think I’ve got a pretty good list of requirements, if there’s something specific you’d like to see in show notes then now is the time to raise it.
Without promising anything and without going into too much detail right now this is what I’m thinking:
Show notes editing will be moved to an external text editor, rather than being edited directly in Cantabile.
Cantabile will monitor the external file for changes and automatically reload when changed - this will let you sit Cantabile and your favourite text editor side by side to edit your notes and see them update when you save.
The file format will be a plain text file with formatting partially inspired by markdown, but with extra directives for Cantabile specific features
Text formatting will be improved to allow inline style changes (eg: coloring a single word)
Images will be supported via a #include directive
Conditional sections will be supported via #if directives.
Timing and auto scrolling will be supported via other directives (I haven’t designed this yet)
ChordPro formatting will be supported via inline fenced blocks or via #include
PDF files will be supported via #include with optional directives to specify page ranges.
This new format will be supported alongside the current show notes but each song file must decide which format to use.
There will be an option to convert the old show notes format to the new - but the displayed result might be slightly different.
I’ve started coding the parser for reading the new file format, but to do everything above could be months of work. So, this is not imminent but something I’m definitely planning.
Hi @brad it’s interesting but here i put my little push on a parallel feature, not properly about the video but about the importing and scrolling of the pdf pages inside the notes section, while playing, scrolling controlled by bindings or media players.
On internet there are many pdf of scores and it would be great if you’d make a pdf import inside the notes tab to scroll it while the gig or to learn something.
The idea could be
have the pages all connected without jump from the bottom to the top of the next/previous page (so the same behavior of the cascade pages in a regular pdf reader)
have a parameter to set the default speed controlled by the bindings or the play, stop and pause event of the current media player. If it was difficult to scroll in a smoothed way it can be converted to a n. of scroll mouse events to simulate a shifting of the pages.
be able to jump to a particular page (plus n. of scrolls) when the cursor goes over a specific instant on the timeline or when a range play event is reached.
integrate the same new loop behaviors made to control the loop jumping.
Thanks for being willing to get into upgrading Show Notes – it’s the one area where i think Cantabile needs to catch up with other such programs.
Your ideas sound sound (can i say that ?). One thing that i’ve always wanted to see in Show Notes would be the ability to format where individual Show Notes go, so that (for instance) one could have a block of text side by side with an image or another block of text.
I’ll probably think of other requests, but that’s all i can come up with at the moment.
Thank you @brad ! Yes the idea of the external editor is great!
I would suggest, in addiction to write the text manually, to have a toolbar with buttons that can call the function like the “Import image”, “Import pdf”, “Bold”, “Chord” etc…to click and change in realtime the text code file and see in realtime the updated result on the monitor (like the CKeditor for the WYSIWYG or the same tollbar i’m using right now to answer you in this forum
).
I made a similar approach to make a component in a C# net framework app to write RTF content because there wasn’t a toolbar to do it (nobody would write RTF manually! )
If you need i can share the code with you, just to have more reference data to manage.
I think this approach would be the best to speed up the customization of the notes.
Well, the whole idea of using an external editor is so you can use the editor of your choice - and I’ll probably be recommending VS Code as I hope to include some syntax highlighting smarts for it. Not sure if I can provide custom toolbars for the editor easily, but will keep it in mind - would be nice if I could.
For the interim period there will be the choice to use the old notes system, or switch to the new one. Eventually I think I’ll remove the old note system, but by then I would hope the new system has been fine-tuned enough that anyone can use it. It’s a fair point though and I’ll keep it in mind.
For the existing notes, they will work as before and not get any of the new features. There will be a command to “convert” to the new system which will take the existing old notes and convert them to an external file for editing.
Hi Brad, this one really got me excited. Especially PDF support is something that Cantabile would greatly benefit from.
Here is my current workflow:
I’m using a latex template with the leadsheets package to compile leadsheet PDFs for my band
Use ImageMagick to convert the pdfs to png files
I then add some red horizontal bars in paint to indicate state changes (also I’m adding a few pixels of the next page so the bottom of the current one to make sure that I can see the chords before switching to the next page)
The state behavior for the “hidden” property of notes is set by default (also set to non-linked)
I drop in the PNG files as background images and hide/unhide them accordingly so that each song state shows the corresponding leadsheet page
Now with that in mind, here are my thoughts regarding your ideas:
Sounds good, however, I would maybe keep the basic text editor so that we can make simply tweaks without having to find the correct file first. Also some kind helper function for browsing image files would be nice.
Maybe you could provide an example of what you envision here. Does this build upon the expression and string variable system?
Sounds great. Can we have bindings or something else to control the scroll position and speed per song state?
This would solve a lot of issues for me.
I could just add my “song state change” markers in latex and compile them conditionally and I would never have to start paint again in my life.
We wouldn’t need to worry about the dimension and resolution of png files
File size (not really in issue but nice anyway)
It would be extra cool if it was possible to display a specific page and use the remainder of the screen to preview the next page (maybe with a slightly darker background)
Will this also convert background images to #include directives? At least for otherwise empty notes it should be pretty safe to do.
I’m not completely clear how my way of work could look like with the new system. Some potential options could be:
The “hidden” property works as before and I just have one note file per PDF page. Each note is just a single #include directive and the song state controls which note is shown. - This works but there would be multiple one-line files per song to keep track of. This is basically just what I’m doing now with an extra indirection.
I can somehow use the #if conditionals to react to state changes - Allows me to manage the notes in a single file per song. However, this requires some manual work to keep states and the conditional statements in sync. From a conceptional perspective, this moves the control over what is shown from the song to the note files. I guess this undermines Cantabile’s state behavior design a bit.
Some system where the page number of PDF directives can be controlled by song states. - For my specific workflow, this would be the best solution. I could just automatically generate the note files and use states to control the page number shown.
I was thinking that every song file “mysong.cantabileSong” would have an associated notes file “mysong.cantabileNotes” and in Cantabile somewhere there’d be a command/button to open the notes in the editor of your choice. ie: there’s one notes file per song.
I will when I’ve figured it out. At the moment, I’ve got the parser’s directive syntax sorted but haven’t yet decided exactly what conditional things can be tested - but it will probably use Cantabile’s existing expression engine.
I also haven’t fully worked out how states and notes interact yet.
I was hoping to make this more based on cue points. So instead of having to calculate scroll rates you can say at this time, this should be visible with directives to control when to start scrolling and when to land at a position.
That said, there’s no reason this couldn’t be controllable by bindings. eg: perhaps a way to mark anchor points in the notes and bindings to scroll to that position - either immediately or over a period of time.
More design work is needed here.
Hrm… thats probably going to be more up to the content of the notes file itself - Cantabile will just display whatever’s next in the file. But being able to grey out a sections of a PDF is an interesting idea.
Yes
No, there’s no concept of multiple note files per song - just one file with everything in it.
However… I was planning for #include to also be able to include another notes file - so you could have a other notes files with shared styles or elements.
Yes, but as mentioned exactly what that looks like I don’t know yet.
Brad…any chance the text for the Show Notes could allow different color text? Using a different color for verse/chorus/bridge, etc. for me personally would be most welcome. I imagine it might be difficult/more difficult if it is scrolling text. Either the text or possibly the background could be altered?
Will this update include the WebUI? Having the WebUI display the exact same screen as the notes would help. When texts and formulas are added, the text does not appear in the same spot on the WebUI screen as the Cantabile Notes screen. Trial and error used to position the text on WebUI. What about having the Cantabile Notes being able to provide different information to multiple screens (same with WebUI). Singer wants the lyrics on a screen and guitarist wants the chords.
My typical method of Notes is to make a static *.jpg in PowerPoint with all the information and set that as the Cantabile Notes background. Then, add the dynamic text/formulas/information as overlays. Push a Volume Pedal, then the Notes show 0-127.
I was going to ask if there can be multiple note files. Currently I have multiple note blocks, some of which come from a template and shared across songs (they show status info).
Sounds like that can be replicated if song note files can #include some common note files?
Also, some updates in the horizontal alignment area please. Currently it’s quite hard to lay things out other than vertically and it can lead to wasted horizontal space in a note block. Think Microsoft word Vs publisher.
The #if directive. Would that be for controlling visibility of a section?
Will all the same expressions and variables from the on-screen keyboard be available?
I use notes for lyrics, chords, and song direction. I use a state change for every page change. There is a color for every state on the left menu, which is also reflected in notes background color, or text. So, when I press a foot switch, the state changes with color changes. That way, I know the state successfully changed.
There are only a few text, or background colors, that doesn’t get lost in in the background. I am limited to yellow, blue, lime and orange.
While I am very open to change, I am concerned about the nearly 1000 songs I’ve constructed through the years. I understand there may be a choice to accept the new change or not, which would be good until I am able to make the adjustment.
Thanks for your interest in the changes.
The current show notes already supports setting the color of both the text and background of an individual note. This will be still be supported in the new show notes. The biggest difference here is the new system will allow inline styling (eg: bold/color/etc… a single word or phrase as opposed to styling a whole paragraph).
This is a tricky one and I’d like to understand a little better. What exactly are we talking about here - is it the point at which text wraps?
That’s a very interesting suggestion. Let me think about it… would you prefer to have a single notes file where you mark out what gets shown to who, or would you prefer completely separate notes files for separate screens? (this might be a later enhancement)
Yes.
This was mentioned above and my only thoughts at this point are some directives to say “split vertically” and then markup for which parts go on which side.
Yes
Possibly… probably.
Don’t forget you can reconfigure the colors in Tools → Options → Colors. That should let you create some more combinations if you need them.
In the new system I was planning to allow using those built in preset colors but also direct RGB and named HTML colors.
Don’t panic! I’m not planning to remove (or even alter) the old system until I’m sure it’s obsolete.
Thanks everyone for the feedback, this has been really useful. Keep it coming if you’ve got other ideas.
Jeez, I have my work cut out for me on this.
Just to set some expectations, I’m planning to spend the rest of June on some minor improvements/features and will probably not start on this in anger until around mid- to late-July.
My Comment: I have no preference as to how (I can’t even begin to make a recommendation!). I believe that having multiple note screens for different musicians synchronized, yet showing pertinent information for that particular musician/instrument, would be helpful in a live stage environment. Everyone wants the Name, Key, Tempo, but maybe vocalist needs full set of Lyrics, drummer needs intro, rest might need backup vocals parts and partial lyrics, etc.
A thought on the different notes per screen. What about a function to parse a notes file? So the default notes view just does as you’re planning (loads a note file for that song) but in the webUI, you could give a different note file (songname_singer.notes) and the function would render those notes.
