Maestro

Beams.

Beams.

Yup! It’s on my (long) list of things to do. Implementing it won’t be straightforward, as beaming rules are fairly complicated things, and Maestro’s file format is very non-extensible. There’s only one bit per note spare in the current spec, so there’ll be work involved in getting a beaming system implemented in a way that keeps compatibility with older versions of the app. I think I can see a way to do it, but it’ll involve tinkering with Maestro’s (very crude) memory allocation methods.

In case of interest, my current plans, in rough order, are:
- Implement vertical adjustment for rests, so that in multi-part staves they don’t overlap notes
- Get tied notes working properly (ie the tie actually extends to the second note)
- Implement chords, so that single groups of barbed notes don’t have multiple overlapping barbs
- Implement score titles, saved MIDI channels, and all the other bits of the spec that never got done
- Rework the internal memory system to use a flexible heap, rather than reserving a fixed 640K for every tune (even if it’s only a few hundred bytes long, as many Maestro tunes are)

Only when all that’s done will it be practical to look into beaming.

I’d been toying with the idea of suggesting a bounty, as even a relatively small one would make it easier to find time to make these changes. But Maestro’s a pretty niche interest, and will never be more than a basic music processor, so I doubt there’d be much interest.

How does Maestro recognise the number of ports (which pretty much corresponds to the number of connected instruments), and how does it score instruments?

I’m working on the USB MIDI module, which will support up to 4 ports. Currently Maestro offers, as instruments, “Internal 8-bit sound system” and “MIDI device”, the latter being singular although I have two interfaces present and SWI MIDI_Init is returning a value of 2. The module is very much WIP, so multiport support is only just creeping in. Well, staggering in, really… so it may not be returning what Maestro needs.

I’m suggesting that SWI MIDI_Init should return the number of valid devices in R0, i.e. USB MIDI devices that are present, which is subtly different from the number that it can support. Also I’m suggesting that R1 should return a bitmap of the valid devices, ‘cos it’s possible to unplug a lower-numbered device, and the remaining devices won’t be renumbered (that would be chaos).

It is in theory possible to support more than 4 USB MIDI devices, but there are some parts of the old Acorn MIDI spec that limit support to 4, i.e. we’d have to change the API a bit. I don’t think that more than 4 devices is a realistic requirement. Discuss…

A CLI command to choose the default port could be nice too, no?

I’d also like to be able to set my own default choices, e.g. default to MIDI if available, and with a more sensible mapping of staves and lines to MIDI channels.

And, for heaven’s sake, let’s NOT crunch the BASIC! That causes me a real headache by preventing any improvements of my own.

I’ve barely looked at Maestro’s playback routines. The only change to the interface I made was to actually select between Internal and MIDI: before, if the MIDI SWIs were recognised at startup, then Maestro sent output to both the Internal and the MIDI module.

How does Maestro recognise the number of ports (which pretty much corresponds to the number of connected instruments)?

From a quick look, I don’t think it makes any attempt to deal with ports. I don’t know anything about the MIDI API yet – does the old Acorn spec allow specifying ports in the way you suggest?

How does it score instruments?

The same way it does for the Internal system: eight single-voice channels, each of which can be assigned to a MIDI channel.

I’d also like to be able to set my own default choices, e.g. default to MIDI if available

Yes, that would be good. At present Maestro has only the very barest support for MIDI – it doesn’t even save the assigned channels when the file is saved.

I don’t know anything about the MIDI API yet – does the old Acorn spec allow specifying ports in the way you suggest?

The Acorn MIDI User Guide is available as a PDF here

Rick’s guide to his updated module is here but two caveats apply: one is that you may need to view it with an 86-based PDF viewer (I found that, using a RISC OS based viewer, it took longer to render a page than I was prepared to wait), the other is that some of the limitations and restrictions are being removed. For obvious reasons I want to end up as compatible as possible with the Acorn spec.

Re. beams: I was just reading PRM vol 4 about Music file format, and beams claim to be supported, albeit rather crudely, i.e. each note has a bit to say “join beams (barbs) to next note”, but a bit of experimentation with hex editing shows that Maestro 2.10 (08-Dec-18) ignores the bit. I just put 5 quavers down and tried. The adjacent bit is for ties, and a tie is rendered, so I know I’m in the right place.

a bit of experimentation with hex editing shows that Maestro 2.10 (08-Dec-18) ignores the bit

Yes, Maestro does nothing with that bit – it seems to be an unfinished bit of the spec. Whether it’s even practical to implement a proper beaming system with only one bit-per-note spare to store the data, I’m not sure.

Whether it’s even practical to implement a proper beaming system with only one bit-per-note spare to store the data, I’m not sure.

I think the proper interpretation of that statement is that:

1. The current and historic versions of Maestro do nothing with that bit and therefore it could be used by a modified version to indicate the active status of some other bits all of which would be ignored by the legacy versions.
2. Provided the legacy is respected the specification is open to modification¹, although a change that broke backward compatibility might be deemed worthwhile.

¹ It’s open source to make things easier to do not to allow people to lament how things might be better if anyone didn’t mind the result not working on machines so old they make us look youthful.

a change that broke backward compatibility might be deemed worthwhile

True, but I’m hoping that the changes listed above can be implemented in ways that don’t break any compatibility wth older versions of the app. There isn’t a lot of flexibility in the spec, but with a bit of care I think useful extensions can be made that don’t break anything. We’ll see!

which would be ignored by the legacy versions.

Or alternatively create a type 3 file format that is better designed, and relegate type 2 as an “export as” option, with the expected loss of data…

It’s worth noting that while Maestro can load the type 1 (Arthur?) files, it cannot save them, so Acorn weren’t too worried about their own backwards compatibility. :-)

As has been pointed out, the format already allows notes to be joined, and I have a very vague memory of seeing that working a LONG time ago. I can’t remember now whether I did that or whether somebody shared it with me. I remember that it didn’t look very good. Perhaps it was mine.

Since Maestro’s format is blocky, one can trivially add a new block type containing data to improve the typesetting. Old versions would ignore that block. Blocks don’t have lengths, so, no.

I think Maestro’s already-documented format contains enough information to add beams. I just did a little experiment.

I wrote the same ten quavers two ways. They are two lines of 5 on the same stave: GABCD and CDEFG. In one file, I added them line by line (i.e. GABCD first, then CDEFG). In the other, I added them one above the other, i.e. GC, AD, BE, CF, DG). The files are identical.

The important lesson is that the musical lines are stored as lines, so there’s no doubt about which note a beam will finish on, regardless of the sequence in which they were entered.

There is, of course, a whole lot of stuff to be decided about the user interface and how the beams are positioned.

Or alternatively create a type 3 file format that is better designed

The problem is that Maestro’s check on a file load is for (a) Type 1 files, or (b) Type 2-or-greater files. So you could define a Type 3 file with improvements that break things, and all old Maestros will merrily load them up and try to process them, with no warning to the user that strange things might happen. When I looked at it, I decided that it was best to improve the Type 2 files to the extent possible. If you got to the point where no further improvements were possible without breaking changes, then it would probably be best to allocate a new filetype.

Blocks don’t have lengths, so, no.

Yeah, it’s not straightforward to add more data to the saved file and keep compatibility. In terms of beaming, I think you’d have to calculate the various stem lengths, angles, groups, etc each time and store the data in memory.

I think Meastro’s already-documented format contains enough information to add beams.

Maybe, but beaming is a fiddly thing to get right. You’ve got to be aware of chords (so that only the lead stems are barbed/beamed), and the grouping of notes per beat, and handling runs of variable-length or dotted notes, all of which is made harder by the paucity of data Maestro actually stores in its file format. I haven’t started looking at it yet, so don’t know what the best system will be, but I think it’ll need a bit of thought.

you could define a Type 3 file with improvements that break things, and all old Maestros will merrily load them up and try to process them, with no warning to the user that strange things might happen

All versions of Maestro will stop and close the file once they hit a block that isn’t in the range 1-6 (but they will also do TERRIBLE things if they hit a block outside the range 2-9 before having seen a block 1).

but they will also do TERRIBLE things if they hit a block outside the range 2-9 before having seen a block 1

Yeah. The PRMs blithely state that blocks 1-9 can be placed in any order, but in practice Maestro needs to see 1-6 first, and doesn’t cope at all with 7-9. I put a note to this effect on the Wiki version of the file format docs. Fixing the file loading is on my to do list, but it’s low priority, since in practice Maestro always saves the blocks out in numerical order, and I’d imagine that the very few other apps that can save in Maestro format do the same.