MIDI card and Sibelius

@Steve F.

R-Comp have apparently got a fair bit of experience of supporting Sibelius systems for clients, as I understand it. CJE may, or may not, have similar.

So did DataStore in Bromley from whom I bought it, but they have long since gone.

Rick: This newer version works as well as the older one did! Thanks! I found out that your module existed because www.riscos.fr pointed to it, otherwise I had not added Midi to the emulator. What must I do to read incoming Midi data (from a musical keyboard) to emulate incoming keypresses? Atm i simply pass on the Rx commands. Is this enough to make keyboard input functional?
Colin: it’s just emulation, Sib writes in 4 colours to emulated memory; but when one sticks a spriteheader just before that memory, one can regard spriteheader+memory as a sprite, and plot that sprite to the host screen in any bit-per-pixel resolution one wishes, be it 2bpp (BBxM,RPC,TI), or 8bpp and above (RPI,Iyo). Riscos does that automatically. When you make Sib entirely 32-bit compatible, so that it can run natively on newer hardware, you would for most target machines need to program in some extra code to convert the original 2bpp writes to 8bpp or 24 bpp; BBxM and Ti apparently can have their desktop / screen memory in 2bpp so do not need this extra conversion, as I understand it.

Doesn’t seem to be pointed to from your site.

It doesn’t have a web page, bit it’s pointed to from here…
https://www.riscosopen.org/forum/posts/search?q=usbmidi&submit=Go

And it’s in ‘C’???

Yup. There’s no need to “use assembler for speed” these days…

There’s no need to “use assembler for speed” these days

No, but I understand assembler, whereas C is an incomprehensible tangled mess to my eyes…okay, I know that’s just me…

Nah, C is a tangled mess. C++ is that with added random punctuation. ;-)

Rick – any chance of USB > MIDI being a ‘C’ Demo?

There seems to be talk on the web – about the USB MIDI dongles – being prone to ‘Latency’ – I presume that means that if a MIDI keyboard key is pressed – it takes a while for the computer program running to respond.

Better to have a PCI MIDI card?
Would what you have done be made to work with a PCI_Express MIDI card?

Any examples of programming a PCI_Express card – is it something like a Podule?

I noticed that there was a sort of Breadboard PCIe card being sold – Theo’s road?

Looking at the back of the ‘Ti’ motherboard – is that the two PCI_e ports at the back righthand side?

To Jan: How come you didn’t use ‘aemulor’ :-)

I get the impression Jon fixes the programs on the ‘fly’ at startup!

It would be nice to see if Sib could be made to run with ‘Viewfinder’ on the RPC.

Is it that simple – that a 4 col sprite can be copied to the whole screen by a OS swi?

ADFFS is a faster emulator than mine (mine really struggles on Iyonix)

Possibly because it only emulates the I/O chipset, the CPU code runs native with only a few changes for incompatible instructions.

while my solution does not require any changes to Sibelius at all, the number of changes for ADFFS should be manageable as Jon has proved so many times with his games.

If it’s well written it shouldn’t require any changes, they’re mainly bug fixes or to prevent code elevation if it’s self-modifying. The majority of bug fixes are C code with Page Zero access bugs something rarely seen in assembler based software. Sound buffer fill code that’s initiated after its started is also another very popular bug.

Back to the point…I’m currently adding Wimp app support to ADFFS, so now’s the time if folk want me to look at Sibelius. If it relies on T1 then getting it working under the Wimp might be fun…there’s no high precision timer API on RO5, so we’re limited to 100hz. ADFFS works around this for full screen games by emulating timer ticks during the frame blit – timers are only used for palette swapping in games. This won’t be possible under the Wimp as there’s no blitting going on…unless I emulate a 50hz frame blit but don’t actually do it, but that might impact Wimp speed considerably.

However…if Sibelius is run under a legacy 4/8 bit screen mode, ADFFS can switch to IOC/IOMD emulation and RISCOS will then switch to using DA2 for the frame buffer with ADFFS blitting it to the GPU. I might need to make some changes for this to work as currently ADFFS only does this for tasks it knows about – it would need to be system wide so all apps are redirected to DA2.

All conjecture until I’ve seen it.

I get the impression Jon fixes the programs on the ‘fly’ at startup!

It’s run under a JIT, so it’s fixed Just In Time.

Is it that simple – that a 4 col sprite can be copied to the whole screen by a OS swi?

I’m sure Jon is best placed to produce a solution based on his wealth of experience, but as a general point ‘simple’ is in the eye of the beholder.

It certainly is possible to fool Sibelius into thinking it is running in a 4 colour mode when actually the VDU system has been redirected to a sprite for the duration of its redraw. However, this may require various bits of tomfoolery to maintain the illusion, including:

• Post- and PreFilters on Sibelius to redirect the VDU to a sprite during redraw requests.
• Intercepting Wimp_SetMode during Click or Menu Selection events.
• Intercepting OS_ReadModeVariables at other times, such as Receive (Post mode change message) and Click or Menu Selection (when going into ‘edit’ mode).
• Intercepting OS_SpriteOp if Sibelius does any writing to sprites itself, and tries to return to the screen by using the default values instead of the returned values.

Such a fix would be applied to Sibelius without it noticing. Another solution might be to patch Sibelius to use scaled & transformed SpriteOps instead of the old ‘fast’ same-mode ops (if that’s what it uses). The four-colour mode is merely a redraw speed optimisation after all.

Which of these two approaches is ‘simpler’ depends on a number of factors!

There seems to be talk on the web – about the USB MIDI dongles – being prone to ‘Latency’

You pay a fiver for a dongle from China with free postage, you get exactly what you pay for.

It is a serial data stream collected and turned into packets by something with less processing power than a credit card…

I presume that means that if a MIDI keyboard key is pressed – it takes a while for the computer program running to respond.

Keyboard to serial; serial to USB; USB to host…

Better to have a MIDI device that can talk USB MIDI directly. My Yamaha keyboard does this.

Would what you have done be made to work with a PCI_Express MIDI card?

Nothing. I don’t have a machine with PCI, nor hardware to test, nor specs.
The usual story. ;-)

A lot of MIDI devices these days talk USB directly…

USB-MIDI FTW

@Colin: Sibelius on Aemulor complained about ‘unsuitable screen mode, change the desktop to at least 16 colours or increase the screen memory’. Then one has to try something different.

Jan – If my memory is correct – that error msg – sounds like Sib telling you – there are too many entries in your MDF (mode) file – if they are too/many – it doesn’t cycle through them or have space set aside to take them all at once.

The RPC didn’t seem to have – many setting in its MDF when first made.

[edit1] By the way – I have converted several Sound Modules to 32bit.

@Colin: My RPC3 has 13 MDF entries, not overly many, but Sib refuses them. Otoh Aemulor+Sib do run on BeagleboardxM (RPC+ARM610 setting), although without Fastclock (notes arrive in groups each second or so). Sibelius appears to need to find a 2-bpp screenmode (in the current resolution). Perhaps it also works on Titanium then? From the fact that it, the demo at least, does run with Aemulor. if something is done for the bpp-setting, one may expect that it will also run under ADFFS.
@nemo: ‘USB-MIDI FTW’ = failed to work?? in that case, my first purchase (Roland) did not work either, too advanced, second one did (Bespeco).

No, that’s v0.03/alpha8 (May 2015). Since then I’ve completely recoded the device detection (alpha9), fixed some bugs, made stuff better for “cheap” devices, etc (alpha10).

Oups! Now OK.

Sibelius on Aemulor complained about ‘unsuitable screen mode, change the desktop to at least 16 colours or increase the screen memory’

I took a quick look at what the demo does last night. It enumerates the screen modes using OS_ScreenMode 2 with a fixed buffer size (&2800), and doesn’t check if there’s more to enumerate after the first call. It assumes the returned structure is format 0 where there are no text based mode names and uses the first four chars of what should be the “mode name” value for something – not sure what as it would always be 0 in the OS at the time. The code looks like its just trying to find the current mode as it will fail if it’s not in the first batch of modes or if it’s above 8bpp.

It will possibly pass the mode test if the current Wimp mode is 8bpp and defined early in the mode definition file – assuming they’re returned in file order under RO5.

EDIT: I forgot to add that if the length of data returned by OS_ScreenMode 2 is greater than &27CE it will error regardless.

Tried this out Jon. With an ultrashort MDF on Iyonix and using the first entry: Sibelius demo runs under Aemulor !!!. Desktop returns in 2bpp, no problem. And there’s no fastclock of course. Sib/Aem on RPI3 no success, no matter what MDF i give it, presence of ‘disable-mode-changes’ in CMDLINE.TXT and/or !Anymode make no difference. BBxM works, but problem with Fastclock.
Can we agree on an advice to the OP: suitable machine (which he has) and short MDF ?
Remaining problems: transfering the Sibelius setup to new machine in such a way that it still works, and fixing the fastclock problem.
My thoughts on fastclock: the current problem is that Sibelius inspects the fastclock counter and, when it has run out, sends a bunch of Tx commands in one go, with timing for each of them in R1. This results in one massive sound once every second. It would be far less massive if it did that every centisecond; millisecond is ideal but unavailable.
So the MIDI module should have a buffer for incoming Tx commands and a fastclock-timer counter.
Register to the centisecond timer and everytime that event occurs, advance the fastclock=timer counter 10 ticks.
If fastclock mode is ON, if a Tx command arrives, inspect the time in R1, if zero then send it to USB immediately. Otherwise put it on the buffer with timing=(current fastclock time + R1). When the counter increments (+10 each time), inspect the times of the commands on the buffer; any command whose timestamp becomes equal or less than the fastclock-timer counter should then be sent to USB. In my emulator things are done in a similar way and I think one cannot hear the difference between this and when played on Archimedes + MIDIcard.

And there’s no fastclock of course

Is fastclock a Module? The demo doesn’t contain it and the !Runimage doesn’t appear to use any IOMD timers.

Sib/Aem on RPI3 no success

As far as I can tell from the code, it wont open on any machine that doesn’t support a 16 colour mode at the resolution of the current desktop…and complies with its shortcomings around OS_ScreenMode 2.

Desktop returns in 2bpp

It’s using Wimp_SetMode when it should be using OS_ScreenMode, if it left the Wimp mode alone it would return correctly to the desktop.

@Jon: Fastclock timing mode is one of the two timing modes that the MIDI module can make use of. One is 100 Hz, the same as for the sound system; the other is 1000 Hz or fastclock timing mode. It’s all described in chapter ‘Timing’ in the MIDI manual mentioned earlier, at page 45 or 47 (paper) or page 53 (PDF).
’It’s using Wimp_SetMode when it should be using OS_ScreenMode ..’ that’s why I do appreciate that you offered to have a look at Sibelius, and I hope that David is willing to send files to you. It would be great if this program could be made to work again.

With my 32bit Demo version 2.50p (6 Feb 1995 running VRPC-DL RO5.25

Iv’e just grafted in the OS_ScreenMode – it returns to the Desktop with Zap & Reporter showing text in half size – f12 Rtn sort of fixes it.

StrongEd is not effected.

Also notices it will start in 64 thousand – and return same – wrong colour in small window – in desktop.

Plays music ‘Jerusalem’ scrolls screen ok – uses Sound samples/modules.
Not tried it with MIDI ESPSynth.

Does not like returning to Desktop 16M colours.
Also noticed no ‘Main Window’ in Templates file.
The prog looks close to be – full mulitasking.

Also – have the file formats changed over time?

Looks like it – by trying a Demo sample in an newer version.
Is the file format based on the Draw format?

Also by changing three instructions – you don’t need to Timestamp the Dir in Scrap – so people who have lost/have a damaged floppy disk – or have replaced a broken HD – can still run the prog.

Fastclock timing (is that part of the MIDI module?) – more up Rick’s street.

Some examples please as a side issue anyone know where I can get a 32 bit versions of midi support etc

I missed the fact we’re talking about two things here, Sibelius and the Acorn MIDI API. Sibelius doesn’t appear to do anything fancy or require external libraries, so should run under Aemulor just fine provided it’s shortcoming around OS_ScreenMode 2 are resolved or worked around with a small MDF file. I’ve never used Aemulor, so am not sure if it emulates 16 colour modes, but 16 colour mode support is a must.

For MIDI a USB MIDI driver that complies with the Acorn MIDI API will need coding, if one doesn’t already exist. As there’s no Timer API for RO5, fastclock mode can’t be supported although it could be fudged down to cs timing, possibly with larger I/O buffers to cope with large amounts of SysEx etc.

Back in the day, I wrote the driver for the EMR Quad MIDI Podule. It must have been before the Acorn MIDI API was defined though as I don’t remember implementing it, I’ll have to dig out the source code and take a look.

My MIDI module does not support scheduled MIDI Txing. It seems that the open sourcing of MelIDI has fallen by the wayside, and I don’t have anything else that “talks MIDI” so there’s nothing to test upon… Maybe some day, when I don’t have a million other things to do.

There are three timing modes to MIDI. The first is using the BEATS counter. The second is the centisecond ticker. This is the one that my MIDI works with. The final is the millisecond timer, which I would imagine is derived from one of the IOC timers (in the original Archimedes).
My module fakes the millisecond mode (centisecond times ten). Because it hangs off TickerV for reading the USB data (and requires a CallBack in order to do so), I don’t think it is viable to go any faster.
Certainly, some calculations at this end based upon the ~33kbaud data rate suggest that centisecond should be “good enough”. That’s a error margin of one hundredth of a second.

Certainly, some calculations at this end based upon the ~33kbaud data rate suggest that centisecond should be “good enough”.

No, it is not good enough for everybody. When you spread a chord, quantising the timing that coarsely makes it sound ragged.

I’ve just grafted in the OS_ScreenMode – it returns to the Desktop with Zap & Reporter showing text in half size – f12 Rtn sort of fixes it.

Without showing my reasoning, the best option is to stop Sibelius from changing mode at all. This can be imposed on it without it realising what is happening, as I’ve described, or it could be modified. Neither of those is trivial.

However, if it is multitasking in ‘edit’ mode, then OS_ScreenMode is definitely the wrong way for it to change mode. Definitely wrong.

Wimp_SetMode does not just set the mode. OS_ScreenMode is not a suitable replacement in itself.