In working on cantabile-media-server it started to dawn on me that it might also serve as an excellent way to build Cantabile’s new show notes feature as discussed here.
There’s a number of advantages to this approach including:
More sophisticated rendering options using HTML and other web and browser technologies
Still MIDI controllable via cantabile-media-server
Support for multiple local and remote viewers (eg: showing different notes to different band members and using remote devices tablets, laptops etc…)
There’s a couple of downsides like it appears as a separate window and requires running a separate program for the server, but I have ideas ( “concepts of plan” ) for how to work around these down the track.
Anyway, as a proof of concept I thought I’d start by building a simple MIDI controllable PDF viewer…
When I first looked into this a couple of weeks ago I thought I could just use the browser’s native PDF rendering and then use scripting to control scrolling etc… but the browsers don’t really expose the ability to do this which is really a requirement because there’s not much point showing a PDF file if you can’t scroll it using MIDI control through Cantabile.
I looked into a couple of options for browser-based rendering of PDF files, but they were complex and cumbersome. Instead, I thought I’d try having cantabile-media-server render individual pages of the PDF to an image and have the browser display them as a series of images.
Demo
This afternoon I did some experimentation, and it seems to work pretty well. In this demo you can see
On the left: Acrobat Reader showing the original file.
On the right: browser showing single pages as rendered by the server (using ghost script)
Comparing the two I can’t see any noticeable or even significant differences. (If you’ve got a particularly unusual, complex or different type of PDF you would like to use let me know and I’ll test it out).
Next
Per page e-tag caching so the pdf doesn’t need to be rendered each time the browser shows it, (ie: browser side caching)
Setup something that can render multiple pages to look like a document
Thank @mavriq, I agree, I think there’s real potential here, but to clear, for the moment it only supports images, video and PDFs. The plan going forward is to provide a simple text file format for generating HTML content - probably similar to markdown, but with additional directives to more tightly integrate with Cantabile’s states etc…
Also, at the moment, this is all external to Cantabile, eventually I’d like to more tightly integrate it with Cantabile, so it’s less cumbersome to setup (not that it’s particularly hard to setup as is)
Rather than use a different CC for every operation I’ve implemented a single command CC (93) that scrolls the document according to the value you send it. I’m not sure about this approach but works for now at least.
Sending these values to CC93 performs these operations:
1: line up
2: line down
3: half page up
4: half page down
5: page up
6: page down
7: home
8: end
other: no-op
These scroll sizes are based on screen size, not PDF page size. ie: a page down operation scrolls by the screen height - not the height of a single PDF page. I might add commands for “next page”, “prev page” which might be more useful in some cases.
Also, at the moment, I’ve enabled smooth scrolling so the document slides as it scrolls. Some might prefer instant scrolls - perhaps I’ll add an option for that.
Finally, the intention here is not really to map controller bar buttons to scroll operations - more likely you’ll use state transitions or MIDI hardware buttons/knobs to control the scrolling.
I just tried 0.0.9 - rendering is superb, and I’m pleased to report that we used the media server at a gig this past week and it worked flawlessly - thank you so much for your effort.
I could see two changes to Cantabile that could be really useful when combined with the server
For automated “next page” type of commands, Cantabile requires a separate trigger at each point where it needs to move forward (e.g. at 23 1.000 move to page 2, at 31 1.000 move to page 3 …). Many more might be needed if automated “scroll by one line” commands are desired, e.g. for displaying lyrics. Could be nice to have a single “multi-trigger” that you could give a list mapping position to page or line commands. Or for lyrics “set scroll speed”, “start scroll”, “stop scroll”.
When I’m at a gig I use most of the screen for notes, but need the controller bar for display of time, master volume, measure and for access to some capabilities (e.g. display set list for next song selection). If this were replaced with a browser I’d lose the controller bar and my limited screen space would be reduced by the usual stuff that appears at the top of a browser window. What about an embedded browsing capability (e.g. github/webview or webview2) as an option inside the notes page?
Yes Markdown would be great. Easy for most people to use. It would be nice if one of the varients is supported so we would get Tables and Color as well.
Rather than a list of positions, I was thinking of timed transitions. eg: start here and end up here in N bars/beats/seconds time.
Yep, I’m aware of this and I think I mentioned above somewhere about embedding a webview in Cantabile. That’s down the track a little… right now I’m just trying to get the tech stack right (nodejs server, web front end, MIDI control, PDF rendering, new show notes format etc…).
Once that’s sorted, I’ll streamline its integration with Cantabile.
Whatever it is I’ll need to write the parser/formatter for it because it definitely has requirements above and beyond what Markdown can do. But… I’ve written a Markdown processor before and it’s not trivial job to do correctly because there’s a lot of weird edge cases that I’d prefer not revisit. So at this stage, best I can say is it will be “markdown like” or maybe “markdown inspired”.
Might work. One of the songs I’m thinking of as a test is Nightwish’s Meadows of Heaven. Starts with a minute or so of instrumental solo before the singer starts, and there are several other places in the song with no singing, so scrolling would need to start/stop accordingly.
antlr works best for structured languages. Markdown is not really structured and I’m pretty sure I’ve seen attempts to do an antlr grammar for markdown haven’t gone well.
Possibly - some sort of syntax highligh colouring at least would be nice.
) for how to work around these down the track.