Maestro and the RMA

Ignorant question #4956 here: Maestro has a little snippet of assembler that runs on start up that checks there’s at least 16K in the RMA, before it runs the app. I’m not sure why it does this. As far as I can see from a quick look at the BASIC source, it doesn’t seem to make use of it. Are there any obvious reasons why it might need to make this check? Or might it be a relic that isn’t needed any more?

It’s probably because Maestro uses the sound scheduler, which (I assume) will allocate from the RMA. Maestro looks like it’s always been a bit memory hungry (the RISC OS 3.6 version happy to take up to 640k, according to git), so for Archimedes machines where you may have had less than that available it was probably important to make sure BASIC didn’t claim all the spare memory and leave SoundScheduler nothing to work with.

If Maestro was able to manage its memory dynamically (growing & shrinking its wimpslot as needed) then you could probably get rid of the RMA check.

Thanks. I’ll look into the Sound Scheduler.

The long term plan is certainly to rework Maestro’s memory management. It currently uses a huge WimpSlot for what are very tiny music files, in order to ensure the fixed allocation is always big enough (as far as I can see, there’s no free space checking at all when adding objects to a score). If it allocated only the memory needed, I’m assuming its footprint would be very much smaller.

The long term plan is certainly to rework Maestro’s memory management.

And perhaps to solve some issues :) Here (very recent rom and disc image), some demo songs just crash my computer. And the others don’t seems to sound right (Pi 3). Does someone still have an old version made before the facelift? Nota: I have some cursor issues too, so perhaps the problem is in RISC OS itself.

And the others don’t seems to sound right (Pi 3).

I can’t say I’ve ever had any problem with Maestro on my Pi 3, but I usually just use it to play fanfare :-). Such a nice tune. Always loved it since my BBC A3000 days.

The visual improvements to Maestro really has made it a much more appealing application. It would be nice to change the bar numbers to be displayed using an Outline Font, rather than the System Font though.

As for the memory/assembly question, I can’t help you at all, but sounds like you could just remove it and see what happens.

And perhaps to solve some issues :)

Send the files to me, and I’ll take a look. chris at cdwraight dot plus dot com

It currently uses a huge WimpSlot for what are very tiny music files

Must resist the temptation to say something disparaging about BASIC’s lack of memory management…

And perhaps to solve some issues :)

I’d settle for it being capable of actually keeping to time.

This is a Maestro file of Erasure’s “A Little Respect”, and a recording (in m4a AAC format as recorded by my phone at the time). It… Sounds abysmal. That “dum-da-da-da-dum” is supposed to run throughout. Not… Well… Enjoy.

(recorded with Maestro of December 2018 vintage, and RISC OS 5.23 on a Pi1)

http://heyrick.ddns.net/files/maestest.zip

The visual improvements to Maestro

Yes. I did the same sort of thing with Ovation (and since I suck at drawing, Matthew Harris provided a better set of sprites).

It’s amazing how clunky the old 2:4 sprites (MODE 12) look, and how much nicer everything becomes with a change to something more in keeping with today’s aesthetic.

Maestro looked embarrassingly bad. Now it doesn’t. Good job!

I second what Alan suggests – it’s rather unlikely Maestro will be used on anything pre-RiscPC, so I’d just comment out the RMA check and see if it makes any practical difference.

This is great Maestro’s getting an update.

It would be nice if there was an SWI to read how much free, unfragmented memory is available in each area. That would also be useful for my Undo / Redo feature for Paint, since some large sprites could be megabytes in size, the history could quickly fill all available RAM on an older machine. I think GIMP uses up to half of whatever the free RAM is for Undo / Redo. I suppose I could attempt to allocate the largest amount of memory possible first, see if it fails and then progressively reduce it to something more reasonable, or would that risk locking up the system?

It would be nice if there was an SWI to read how much free, unfragmented memory is available in each area.

Module area: OS_Module 5
Arbitrary heaps: OS_Heap 1
Total free memory: Wimp_SlotSize “size of free pool”
Maximum size of a dynamic area: OS_ReadDynamicArea
Total memory in the system: OS_ReadMemMapInfo

These should work down to RISC OS 3

Since Paint uses flex, you don’t have to worry about interrogating the C library’s heap, so the largest block that you’re guaranteed to be able to allocate from application space can be calculated via:

min(Wimp_SlotSize free pool size, OS_ReadDynamicArea appspace max size - OS_ReadDynamicArea appspace current size) - 128

The “-128” is a fudge factor to take into account the block header size and anything else flex does internally (I’m not sure what the exact value should be!)

I suppose I could attempt to allocate the largest amount of memory possible first, see if it fails and then progressively reduce it to something more reasonable, or would that risk locking up the system?

Yeah, claiming all the free memory is certainly risky. A reasonable rule of thumb could be to leave max(64K, total_system_memory/100) spare.

some demo songs just crash my computer.

David, did you try and send me those files? I’d be happy to test out against the current and original versions of Maestro.

It would be nice to change the bar numbers to be displayed using an Outline Font, rather than the System Font though.

Yes, it would. I might look into using sprites derived from a suitable font.

In case of interest, the version I’m working on right now handles ties properly (ie extends them, and offers a choice of over or under the notes. You can see the difference in the two images below, which also shows the difference being able to put more than one rest in a column makes (ie, you can actually score multi-part staves properly):

Any help to use CLib calls from BASIC!

David, did you try and send me those files? I’d be happy to test out against the current and original versions of Maestro.

OK, it’s solved… or not :)

I have a sound that crashes completely my computer. The module loads, but the computer crashes if I try to play the sound (abort on data transfer + filecore in use, etc.). Nota: it crashes too when I try to play it with SoundCon. That’s very strange.
https://www.riscos.fr/fichiers/misc/chimes.ffa

This sound is ‘scanned’ or ‘used’ with some Maestro files, and not some others. For example with ShostF7., but not BackFXVI.
So it’s more a system or module bug than a Maestro bug.

I have also a problem with crackling noise on my new ROM… Probably not related.

Have you run the modules through ARMalyser?

---------------------------------
Statistics
---------------------------------
Size in words :    2740  100.0%
Code          :     206    7.5%
surmised      :       0    0.0%
uses PSR      :       0    0.0%
not ARM2/3    :       7    3.4%
not 32 bit    :       0    0.0%
unpredictable :       0    0.0%
Data          :    2534   92.5%
surmised      :    2479   97.8%
Warnings      :       0    0.0%
Unidentified  :       0    0.0%
---------------------------------

On the other hand, it should not crashes the system when playing with SoundCon.
SoundCon can play it as 8bit, but not 16bit stereo (abort on data transfer, etc.).

This sound is ‘scanned’ or ‘used’ with some Maestro files

Currently Maestro files only record the voice number associated with a channel, and this order can vary from system to system. The file spec provides for the names of the voices to be saved too, but this feature was never implemented. When it is, you’ll be able to properly control which actual voice generators are linked to each channel, rather than hoping that the order is the same on every computer the music’s played on. Until then, you can manually change the voice number used by Maestro in the Instruments window to avoid the problematic voice generator.

Any help to use CLib calls from BASIC!

In Acorn User Sep/Oct 1993 Dave Acton presented the SCLMod, which made CLib routines available through SWIs. I had a fiddle with it, adding a couple of routines to see how it worked. 5 years back I revisited it and made it work on an up-to-date machine. I am not sure how the copyright works, but you are welcome to look.

It has SWIs for:

If you are just wanting to manage a heap above HIMEM there are easier ways. My Heap library might suffice.

Bonsoir,
For information the same sequence of the BachFXVI song above converted from Maestro to Rhapsody4
I do not know how to put an image on the forum, I added a link to see it.
https://jeanmichelb.riscos.fr/Rhapsody4.html
In addition, as I have no news from APDL, I will put !Rhapsody4 on my site to download it.
Harriet Bazley helped me by testing and finding bugs, quite a few have been fixed.

For information the same sequence of the BachFXVI song above converted from Maestro to Rhapsody4

That looks great!

Can I send you my local copy of BachFXVI in Maestro format, to see if Rhapsody can load it OK? I’ve used some of the reserved bits in the file spec to implement rest positioning and tie extension, and would be interested to know if Rhapsody can still load the files.

I do not know how to put an image on the forum

There’s a link to the textile reference at the bottom of the page when composing a post.

To insert an image just put ! at each end of the url without spaces.

!https://jeanmichelb.riscos.fr/Download/Rhapsody/BachFXVI.png!

To Chris: Yes,
This morning I tested the import of a Maestro file into Rhapsody2. It fixes the ties, but they are lost in the conversion to Rhapsody4.
Illustration: (thanks to Jeff for the pssibility to put images, I would like to know how to put the text in purple for paragraph, thank you)

I was going to forget: JO Linton did a very good job, it would be a shame to let it get lost, especially as in the field of music scores there is a lack because I do not think there will be a version Sibelius with 32-bit Risc OS and today’s hardware.
Bonne journée.

I tested the import of a Maestro file into Rhapsody2. It fixes the ties, but they are lost in the conversion to Rhapsody4.

Thanks Jean-Michel. The most recently released version of Maestro (2.13) doesn’t extend ties, but it does allow you to position rests vertically. I have a test version here that extends ties also, but it’d be good to test both features, to ensure that any files making use of them import into Rhapsody 2. Do you have an email address I can use, to send you a test file? You’d be welcome to email me at ‘chris at cdwraight dot plus dot com’.

To use the purple quote blocks, use the bq. command with a space:

bq. Quote here

Quote here

Do you have an email address I can use, to send you a test file?

jmc.bruck@orange.fr
I think it’s possible to fix the conversion utility to keep the ties.
In the content of the CD that I bought, there is a technical document which specifies the structure of the Rhapsody files, it is a very good basis, it would be good to keep a homogeneity. I will send it back to you by email.

Thanks. The Maestro file format is documented here, and is almost up to date with the latest changes. These are:

• The first three bits of the second Rest byte are no longer guaranteed to be zero. They are now used to determine vertical rest positions on the stave. The slightly complicated scheme is there to preserve compatibility with older Maestros
• Bit 1 of the first Note byte is used in my test version to indicate whether a tie is drawn over or under the note (0=over, 1=under). If this change is accepted, I’ll update the documentation accordingly

I’ll drop you a line with a few files to test.