MIDI card and Sibelius

Did the MIDI cards generate this freq themselves? – is it possibe for Jeff to bring out the required freq in RO5?

The author of ‘Aemulor’ did say at one time -if I remember correctly – about bringing out low colour modes in a separate module.

‘Aemulor’ does Low colour modes – but locks 28Mb Apps space.

Later versions of Sib7 have an on the screen keyboard.

I presume when a MIDI keyboard is used – the notes are transcribed directly into Sib.
For Rick – Would !StudioSnd do for MIDI testing?

26bit version of !MidiWorks – ‘Aemulor’ – or if it is worth it – 32bitting it.

the best option is to stop Sibelius from changing mode at all

I don’t think that will work as it’s hardcoded for 4bpp

Did the MIDI cards generate this freq themselves?

It’s using IOC T1. Until there’s a Timer API, high precision events won’t be possible. If an external MIDI device can generate timing, you could work around the issue as you’d be getting events from the MIDI timing data.

Did try long ago – for Sib to use 16 Colour modes – but it seems to use VDU4 & 5 -printing all over the place – I suppose it could be doable – perhaps staying with just VDU5 printing.

More space would be required – when Sib switches between 16 col Edit mode and whatever you were using before.

[edit1]
With ref to a timer – could Jeff add this – is it at all possible?

With ref to a timer – could Jeff add this – is it at all possible?

An official interface to the HAL timers is certainly long overdue – discussions have been going on for a number of years, bouncing between a manual claim/release API for HAL timers, to a service call based claim system, to the RISC OS 6 Timer API (docs), and more recently the ARM generic timer. For most apps something based around the ARM generic timer is likely to be the most useful. Maybe if I spent some more time thinking about it I’d be able to come up with a suitable design (IOMD & Iyonix are a bit of a hassle because of the simplicity of their timer hardware).

Some inspection notes:

• OMG it uses an ascending stack. Uggh.
• It uses double-buffering in edit mode – that’ll need to be suppressed
• It requires a lot of flag preservation
• Although there’s an embedded sprite file of 104 sprites, there’s a big chunk of graphics that is blitted direct to the screen – all 4 colour
• As well as double buffering, it grabs the screen as a sprite and then plots it back – perhaps instead of Plot,184+

I don’t think that will work as it’s hardcoded for 4bpp

You’ve not read what I’ve written in this thread.

Sibelius switches to a four colour mode, which is 2bpp. I have proposed Post- and PreFilters to intercept various SWIs and redirect Sibelius to a 4 colour sprite which can then be displayed in a window like a normal application.

Despite the fact that it multitasks in edit mode, it does not cope terribly well with redraws – it does not expect anything to be in front of its window, and the fact that the iconbar can be popped to the front is a total surprise to it (I wonder whether it was started under Arthur, because that’s its model, basically.

It ought to be possible to treat it much like a single-tasking game, but the ‘desktop adaptor’ (the Post/PreFilters) would need to handle the Edit Window specially – Sibelius opens a full-screen window which has no furniture, no bounds, takes hot-keys, no icons, no auto-redraw and is marked with the old GCOL Colours flag. This would have to be turned into a proper draggable window.

The confusing ‘you must be in 16 colours’ error report is just the generic ‘I don’t know which mode to use’ message. The text is bogus.

I’ve never heard of !StudioSnd. Will it run on a Pi2?

To throw some numbers out, one of the issues here is the interfacing between USB and serial MIDI. You see, serial MIDI takes about 3ms to send a note. So to send a three note chord will take about 9ms (not 7 because USB does not support running status). Sending a three note chord and two melody notes will therefore take about 15ms. Or a centisecond and a half. The average ear can detect errors in the order of 20-30ms (or 2-3cs).

It’s a whole different story with USB MIDI. You can fire off a bunch of notes and they will arrive with minimal latency (whatever speed USB works at).

The second issue is that I hang off TickerV; so centisecond timing is the best we’re going to get.
I notice (via a simple NULL poll program) that I get in the order of 400-900 polls per second, so a modern machine is surely going to be limited by depending upon TickerV.
So what I think RISC OS needs is:

• A FastTickerV that works in milliseconds (or something).
• A fast counter (like OS_MonotonicTime) that works at the same rate so that it can be used to stamp events. My understanding is that the HAL timer works insanely fast (2MHz?), may reset often due to rollover, and may be reset quasi-arbitrarily.

Still, for a “quick hack” to see if the idea of talking to a MIDI device is viable… ;-)

I notice (via a simple NULL poll program) that I get in the order of 400-900 polls per second

Oh you certainly can’t rely on Wimp polls for timing anything.

There are a number of systems that want to use IOC Timer 1, which is why it has its own device number for OS_ClaimDeviceVector. A shared ‘fast ticker’ system not unlike OS_CallEvery would be most welcome, but would have to be implemented via the HAL, in general.

Nemo’s cat has found Sib :-)

Rick – Its Henrik Pedersen program !StudioSnd – Search in ROOL site for StudioSound – the main prog seems to BASIC with comments.

There are a couple more links in the chain required for USB MIDI.

For playout, there has to be a way to get the MIDI message scheduled as a USB transfer at the correct time. This is where it gets slightly hazy for me. Playout from something like Maestro, where all the notes are known long in advance, can in principle be done even by the foreground task – but there isn’t a means to tell the USB stack when to schedule it. Then there is the question of what to do if playout is required live – presumably the request to schedule the message has to be done in interrupt mode? but where could such a request come from?

Recording from USB MIDI requires each incoming USB MIDI message to be time stamped to the millisecond. There is no means AFAIK to get such time stamps.

USB frames occur every millisecond. Can we use that timebase directly rather than requiring another timer?

serial MIDI takes about 3ms to send a note

Check your arithmetic, Rick. 31250 bits per second means 32 microseconds per bit. Each MIDI note on is 3 bytes, 30 bits, so the note on message takes 960 microseconds.

Check your arithmetic, Rick.

It doesn’t surprise me that my maths is horribly wrong. A note per millisecond is more reasonable.

A shared ‘fast ticker’ system not unlike OS_CallEvery would be most welcome,

I’d settle for FastTickerV… ;-)

links in the chain required for USB MIDI.

How many hops are there between writing “to a file” (or a USB handle) and the data actually being sent? Is it quasi immediate or does it buffer into chunks?

The important thing, to my mind, is receiving. I think it might be a benefit if the USB stack can recognise MIDI and dump it into a buffer with a timestamp of some sort. That means it can be stamped at a low level, rather than when “whatever” gets around to responding. There are complications (multiple devices etc) but that’s the gist. Luckily USB MIDI is word sized packets of data (SysEx will be split into multiple packets).

Why do you need to treat USB Midi any different to Serial Midi?

To play a file you would read the file from a callback, queue the data for an timer interrupt to determine the amount of data it requires to send in the next timer interval. A serial Midi device would clock this queued data through the serial midi interface at the correct speed. A USB Midi device would send data quicker to the device but A USB Midi port would control the speed it passes data on to midi – ie it outputs at serial midi rates.

If playing from a keyboard you wouldn’t need the interrupt to send data as your fingers become the timing device so you’d just send the keypresses as they are detected.

Dave at the show suggested that there are USB Midi devices which don’t serialise the data through a midi serial port. Is that true? Has anyone tried just sending data directly to a USB device when a keypress is detected?

I’ve never heard of !StudioSnd. Will it run on a Pi2?

See there: https://henrikbp.riscos.fr/

Just in case anyone thinks MIDI is rosy in the Windows world

Nemo’s cat has found Sib

Why do you need to treat USB Midi any different to Serial Midi?

The MIDI UART is a dedicated resource, available exclusively to the MIDI software, which can use it (and the data that flow through it) entirely as it wishes. The USB host is a shared resource with a defined API. This API does not include time stamping, for example.

Just in case anyone thinks MIDI is rosy in the Windows world

One aspect of what the article describes is a common problem when desktop operating systems are used to perform a real-time job.

RISC OS is of course a desktop OS and not a real-time OS. What we’re discussing here is how to make a small part of the OS have real-time capabilities, sufficient to perform adequately for MIDI.

Why do you need to treat USB Midi any different to Serial Midi?

• MIDI events need to be timestamped. Serial data timing is not that relevant so long as all the bytes arrive “soon enough” and in the correct order. Various file transfer technologies (Zmodem, for example) try to maximise throughput by minimising the block-ACK dependencies.
• MIDI data can count for multiple devices in one stream. Old fashioned MIDI has a “thru” port, while USB MIDI has the idea of virtual controllers. Thus a packet of data needs not only a timestamp but also an identification… While the USB packet does cater for some of this (the first byte), it should be remembered that one can plug in multiple MIDI devices at the same time.

Dave at the show suggested that there are USB Midi devices which don’t serialise the data through a midi serial port. Is that true?

As I said earlier, most decent modern devices talk USB MIDI directly (and not via a serial interface). My keyboard is one such device, and it’s possible to send a wodge of data in one go as the interface speed is USB, not 31.250kbps serial.

Oh you certainly can’t rely on Wimp polls for timing anything.

That’s not what I said. What I said was to point out that the Wimp can manage in the order of 1000 polls per second (from my slower Pi to a much faster Ti…), yet the only background ticker we have runs at a mere 100 times per second.

Or, to put it differently, if the Wimp can cope with shuffling tasks at that sort of rate, the machine can damn well cope with a millisecond timer vector. With a processor speed of 1GHz, I make that to be a million CPU ticks per vector tick. To put this into context, TickerV on the original 8MHz ARM2 was 80,000 CPU ticks per vector tick…

I have been reading the thread with interest, and note a few people are possibly proposing changes to Sib and making it available. Would this not break the copyright and IPR of Avid the current owners of the commercial software. Personal tweeks are probably OK for personal use. R-Comp have a way to transfer the software to alternative hardware already.

I have been reading the thread with interest, and note a few people are possibly proposing changes to Sib and making it available

Making changes yes, to fix the issues that prevent it running under Aemulor on a modern machine. There’s no intention to make the product itself available as that would be illegal.

As far as I know – Rcomp have got Sib7 running with VRPC.

No doubt – they would like to be able – also – for it to run on their ARMX6 – a classroom full of new Arc’s :-)

Getting the Software to install on non ADFS systems.

The work here is on ideas – getting the Demo to run on a 32bit only machine.

Perhaps getting around the 4 colour screen mode problem – which has for a long time has caused problems with the Hardware RPC and Viewfinder.

Plus some of the newer machines (except TI-which does) that don’t have 4 Colour modes – without using aemulor.

Rick has done work on a MIDI > USB adaptor software (for keyboard) – it will be interesting if Jeff OS and Colin USB can come up with ideas on making it more usable – with Sib and other programs that have MIDI input.

[edit1] Where else do you find – to be able – to talk to the ones in the OS development :-)

proposing changes to Sib and making it available

I can’t speak for others, but I was proposing writing an independent module that would allow Sibelius to work… not a modification to Sibelius itself.

Modifications for compatibility purposes are completely within copyright law, it just needs to be a standalone “patch” that is applied by the owner of the software (or software licence, depending on the jurisdiction you are working under…try to google for that nice German word “Erschöpfungsgrundsatz”).

If it would be legal for a commercial entity to sell readily-patched versions of licences they have in stock would be an interesting discussion for real copyright experts. I doubt if the current owners of the copyright would have any legal ground for damages or compensation of they cannot prove that it relates to a product they still actively sell. But just because someone cannot successfully sue you would not make it legal of course!

I doubt if the current owners

“Passing off”? If selling a patched version, it is neither what the copyright owners released nor technically “what it says on the box”.

“Passing off”?

I had to google that…sell it from Germany, there is no such law here. And I would be interested if someone has a reference to a law case in the UK with the subject of a “patched for compatibility” type of change.