USB MIDI?

Cannot find a valid endpoint at 800

Strange it detects a bunch and then throws an error. Stranger that it detects the same one several times. I don’t actually know the endpoint flags; I just noticed that all of the ones that send stuff on my system have 128 added to the endpoint address, so I “guessed” that bit 7 was a direction.
I have tweaked the program, so hopefully it will work right away now.

[Note On] channel=0, note=52, velocity=98 octave 4 E NOTE OFF

? It shouldn’t say “NOTE OFF” when velocity is non-zero!

I notice a “[Active Sense]” in your reply, but no indication of a clock. Does your keyboard not output the quarterbeat ticker?

I installed “Zap”, & the “syntax errors” as reported by edit & StrongEd for your BASIC programs vanished. I have no idea why those editors do that.

I had StrongEd on the Pi and really didn’t get on with it. Now I have Zap. The program was written in Zap.

MIDITEST – New version!

http://www.heyrick.co.uk/random/miditest.zip

I’ll yack about it on my blog; but for now here’s what is new:

• Fixed a pile of bugs. Erk.
• Now indicates “middle C”, just ’cos.
• Records the ticker intervals and calculates the BPM. Pretty accurate, but obviously only correct for 4:4 time.
• Pressing a key on the keyboard will cause the corresponding note to play on RISC OS. This is very simplistic – pressing the key will turn the note on, and a note off event will silence it. Sounds okay with WaveSynth. Will shatter zombies with StringLib-Hard on Loud setting.

The note will not silence if MIDI is disconnected or Esc pressed while a note is playing (I forgot, that’s for v0.03!). To silence, drop to BASIC and enter SOUND 1, 0, 0, 0 and it’ll shut up.
Oh, and don’t expect sustain, or the ability to play multiple notes at once. It’s just a “because it looked simple to do” thing. Also was mainly for looking at the correlation between MIDI notes and RISC OS sound commands.

Apart from expanding the program with larger tables of recognised data, that’s pretty much it for the MIDI receive test. I didn’t bother with the tables as many of the options on my keyboard output System Exclusive messages in preference to standard MIDI codes. Like, say, changing the voice to “violin”. Hmm…

@DavidS, where does the HALcome into play here?

Bugs in MIDItest (to be fixed in the next version :-) ):

• Errors don’t silence a playing note. Add SOUND 1,0,0,0 to the second ON ERROR line.
• Playing note will not be silenced by Note Off, if your device sends that. In the IF conditional for turning the note off, add test OR (on% = FALSE)
• BPM is only correct for 4:4 time. Fix to come…

Your tweaked program is better, thank you. I no longer have to fudge the endpoint. Looking forward to your next version.

The velocity / note off was probably my incorrect transposition of an adjacent line. It’d be handy if alternate lines could have a different background colour to guide the eye. I haven’t yet worked out how to pipe screen output to a file so I just typed a few lines from the screen.

Middle C indication works fine. Playing sound is very handy too :-)

“I notice a “[Active Sense]” in your reply, but no indication of a clock. Does your keyboard not output the quarterbeat ticker?”

The output snippet was from the “Uno” converting plain midi from the “dumb” MK-149. If you’d like me to send output from the posh keyboard (all self contained) just ask. That keyboard is much more recent.

All tests until now have been on the recent 512m RPi. Every second invocation of your Miditest hard crashes the RPi. So, today I’ve tried Miditest on the now vintage 256m RPi, & no crashes even after several Miditest invocations.

I REM’d out the MODE 28, hoping to see what was happening in the “Task” window (select on the raspberry in icon bar). Well, miditest doesn’t show up there. Is that the case for all BASIC programs?

I see the BASIC window is immovable when MODE 28 isn’t used? Presumably that’s by design?

I see the BASIC window is immovable when MODE 28 isn’t used? Presumably that’s by design?

The cake is a lie. I mean window. It isn’t a window.

When you run a program on RISC OS it starts as a single tasking program. It has no windowing, and has full command of the screen. It stays like that until it calls Wimp_Initialise (which tells the Wimp that it is going to multitask) and then Wimp_Poll (when it actually does multitask).

Before that, the screen stays exactly as it was when you launched the program, in the expectation that it is going to call Wimp_Initialise. However, if the program tries to output some text, the Wimp realises it probably isn’t going to be a multitasking program, so it draws a little GUI window on the screen, then opens a ‘text window’ inside it.

A ‘text window’ isn’t a GUI-style window, it’s just a delimited set of rows and columns where text is allowed to be output, until something more sophisticated happens.

MODE 28 is actually equivalent to VDU22,28, so also causes the little window to be drawn… but then the mode change happens and clears it. Another approach is VDU26,12 – that cancels the text window (so text can use the full screen) and then clears it (CLS = 12).

I allocated two very useful filetypes – TskBasic and TaskApp – that are excatly like Basic and Absolute except they open in a proper multitasking TaskWindow, which is much nicer in the desktop. I’ll publish the appropriate boot resource some time today. I find TskBasic much more useful than Basic in that regard.

Some time ago, Rick wrote:

I can’t figure out what the hell the “free bytes in buffer” is supposed to represent. It jumps all over the place.

That’ll be the ‘free bytes in buffer’, and represents the number of bytes in the buffer that are free. :-p

It jumps about because while you’re taking bytes out, your MIDI device is putting more bytes in. This should probably be obvious by now, but I never overlook an opportunity to be pedantic.

Your tweaked program is better, thank you. I no longer have to fudge the endpoint.

Yay. Nice to know it works.

It’d be handy if alternate lines could have a different background colour to guide the eye.

I’ll make the text coloured. Different backgrounds is more work (this isn’t ANSI.SYS after all!).

Every second invocation of your Miditest hard crashes the RPi.

How bizarre. What happens? Freeze? Message?

So, today I’ve tried Miditest on the now vintage 256m RPi, & no crashes even after several Miditest invocations.

Well, that (PiB256Mb) is the system I developed it on. ;-) Run it loads of times from Zap.

I REM’d out the MODE 28, hoping to see what was happening in the “Task” window (select on the raspberry in icon bar). Well, miditest doesn’t show up there.

It isn’t a multitasking program – so it won’t appear in the task manager. As explained above, the “window” you see is what the Desktop does when it doesn’t know what else to do (a single-tasking full-screen program should set up the display at the start, so you won’t tend to see the fake window as it’ll get cleared away).

That’ll be the ‘free bytes in buffer’, and represents the number of bytes in the buffer that are free. :-p

Duh. ;-)

It jumps about because while you’re taking bytes out, your MIDI device is putting more bytes in. This should probably be obvious by now, but I never overlook an opportunity to be pedantic.

Here’s a quote – larger listing on the first page.

Byte = 0 Free in buffer = 309
Byte = 0 Free in buffer = 310
Byte = 0 Free in buffer = 311
Byte = 0 Free in buffer = 248
Byte = 0 Free in buffer = 249
Byte = 0 Free in buffer = 250
Byte = 0 Free in buffer = 251
Byte = 0 Free in buffer = 252
Byte = 0 Free in buffer = 253
Byte = 0 Free in buffer = 190
Byte = 0 Free in buffer = 191
Byte = 15 Free in buffer = 128
Byte = 254 Free in buffer = 129
Byte = 0 Free in buffer = 130
Byte = 0 Free in buffer = 131
Byte = 0 Free in buffer = 132
Byte = 0 Free in buffer = 133
Byte = 0 Free in buffer = 70
Byte = 0 Free in buffer = 71
Byte = 0 Free in buffer = 72
Byte = 0 Free in buffer = 73
Byte = 0 Free in buffer = 74

Free bytes jumps from 311 to 248. Reading bytes reads the padding bytes so there is no valid MIDI data in the buffer. Likewise 253→190 then 191→128 then 133→70. Through all this buffer report weirdness, only two valid MIDI bytes were received.

There are two options:

1. The numbers jump all over the place with a pattern as yet unknown; though I observe that the difference in the buffer jumping is 63 bytes.
2. The system generates the padding and stuffs that into the buffer, makes you wonder if there is a risk of data loss due to the buffer being full of all those padding bytes.

And now to write data?

Any ideas?

YES! A Middle C from Pi to keyboard. ;-)

o% = OPENOUT("devices#endpoint1:USB7")

DIM buffy% 4
buffy%?0 = &09
buffy%?1 = &90
buffy%?2 = 60
buffy%?3 = 64
SYS "OS_GBPB", 2, o%, buffy%, 4 TO ,,,nt%
IF (nt% <> 0) THEN PRINT STR$(nt%)+" bytes not sent!"

CLOSE#o%

“… Different backgrounds is more work (this isn’t ANSI.SYS after all!).”

Good point :)

Every second invocation of your Miditest hard crashes the RPi.
“How bizarre. What happens? Freeze? Message?”

Freeze, yes. No amount of ALT – Break, incantations, etc. escapes from it, so I have to pull the plug. I’ll try it on another 512 Pi to see if it’s repeatable.

I REM’d out the MODE 28, hoping to see what was happening in the “Task” window (select on the raspberry in icon bar). Well, miditest doesn’t show up there.
“It isn’t a multitasking program – so it won’t appear in the task manager. As explained above, the “window” you see is what the Desktop does when it doesn’t know what else to do (a single-tasking full-screen program should set up the display at the start, so you won’t tend to see the fake window as it’ll get cleared away).”

Yes, thanks to you & nemo for concise & very helpful information, which I’ve now put into my “essential info’” file :)

“YES! A Middle C from Pi to keyboard. ;-)”

Good progress!

The few devices I have here are input only, so I’ll have to see if I can rig anything up to test that :)

It’s looking to me like this might be a problem looking for the solution of using the StreamManager module that was so helpful in getting sound working on Squeak. Add a layer on top of it as SharedStreamBuffer does for sound and you might be able to produce a really easy to hookup midi stream system.

Latest version of miditest (note – not tested due to LW radio, changes are minor, however so fingers crossed):

• Fixed bugs re. stopping sounds (on error and by note off)
• Differentiated Poly Keypress from Note On (same code handles this – currently Poly Keypress will NOT cause a note to be sounded – is this logical? what exactly is a poly keypress?)
• Noted BPM is in 4:4. Other time sigs will come, unless my keyboard spits out something non-standard.
• Output is now colourised (colour list below). Should aid mental decoding by looking at the colours.

Colours:

System Exclusive and System General (Time Code, Position Ptr) messages are in Magenta.
Single byte commands (Clock tick, Active Sense…) are in Cyan.
Note On is in Green EXCEPT when Velocity=0 which means it is a Note Off.
Poly Keypress is in Dark Green.
Note Off is in Red.
Controller Messages (Volume, Sustain, etc) are in Yellow.
Program Messages (change active voice) are in Cream.
Anything else (Channel Pressure, PitchBend, etc) are in (default) White.

miditest.zip (5K)

John:

Yes, thanks to you & nemo for concise & very helpful information, which I’ve now put into my “essential info’” file :)

Here is another for you. To quote stuff, write “bq. ” (bee, kew, dot, space) followed directly by the text you want to quote. Leave a blank line above the quote, and a blank line to end the quote (Textile’s parser likes blank lines around the place!).

The few devices I have here are input only, so I’ll have to see if I can rig anything up to test that :)

Included in the latest version of the archive is “playtest”. The same as the program above, except it contains a line saying ERROR "..." where the text is telling you to alter the USB endpoint/device. Oh, and delete the “ERROR” line as well. ;-)

Tim:

might be able to produce a really easy to hookup midi stream system.

I was thinking about coding a bare-minimum version of the “MIDI” module. Not looked at the SWIs to see about feasibility, though I can say for sure that I have no plans to implement MIDImod’s “play what it receives” mode. Not unless the sources to the original are kicking around ROOL’s attic…

Does anybody have, or know of, a free program that can accept and play or notate from MIDI input using the standard interface? This is for testing, not me scavenging (I use MuseScore on my PC…). For playback, well a poke around !Maestro’s code is…interesting!

Freeze, yes. No amount of ALT – Break, incantations, etc. escapes from it, so I have to pull the plug. I’ll try it on another 512 Pi to see if it’s repeatable.

If this is repeatable on the other 512Mb Pi; insert:
TRACE ON
at the start of the program. This will output line numbers as they are executed, like [10][20][30][40] etc. The point where it freezes should be the last line number shown, which ought to give a clue as to where/why it is freezing.
<cough>Not that a user mode application written in plain BASIC should be able to bring down the OS…</cough>

If this is repeatable on the other 512Mb Pi; insert:
TRACE ON
at the start of the program.

Repeatable, yes, although sometimes runs 3 times before crashing now!
Right, line 950 currently. Will do some more runs……

Not that a user mode application written in plain BASIC should be able to bring down the OS…

That has indeed crossed my mind ;-)
Oh, I think I will be able to test “Playtest” IF
I can find my old Atari ST AND some synth’ s/w for it. I used to have “Band in a box” but no idea where it is. I’m not a musician, just interested :-)

Rick:

I’ve just tried compiling Miditest with !ABC. No idea if it’s significant, but many warnings of “incorrect number of arguments” for lines containing COLOUR, e.g..,

COLOUR255,255,0

Anyway, eventually it did compile, & naturally crashed :) It seems the crash is usually at some endpoint identified.

I’ll take another look tomorrow (well, later today ;-) )

Right, line 950 currently.

950?! That’s a REM following the BGET#in%.

Try something = comment out the BGET and replace it with b% = 0 and run the program. Does it still crash, or is something going wrong with DeviceFS via the BGET call?
Can’t fathom why it works okay on the 256Mb Pi though.

No idea if it’s significant, but many warnings of “incorrect number of arguments” for lines containing COLOUR, e.g..,
COLOUR255,255,0

Oh, all these not-really-BASIC things that are so out of step with the real BASIC interpreter that it isn’t funny.

Go to BASIC on any version RISC OS 3.50 or later. Type HELP COLOUR. Observe the part that says:

  COLOUR r,g,b: set colour to r, g, b.

<sigh>

It seems the crash is usually at some endpoint identified.

There is no output from then until something is decoded. You might want to insert some commands like PRINT "a" and PRINT "b" etc after important looking lines.

Problem is:

• The in-memory pokage (to parse the USB structure) is read only. If this goes wrong, the application should crash, not the machine.
• There is no other part of the program liable to cause a freeze of this nature. Essentially it BGETs bytes and parses them; the most complicated thing is calling a SWI to make sounds. But it doesn’t appear as if you’re getting that far.
• A total system freeze is symptomatic of something trampling over the exception vectors. On an older system, entering !8=0 would freeze the machine (sets SWI vector to nothing – instant death). It is almost as easy on a newer machine, but that’s left as an exercise for the reader (and don’t post here when you work it out).

What gets me is that it works on your 256Mb Pi, not to mention my 256Mb Pi, but it fails with the 512Mb model. Is it related to the Pi memory size? Is it related to memory size period? I think I will need to fire up my Beagle over the weekend and see how it behaves on that. You said you were going to test it on another 512Mb Pi (ummm, how many of them d’you have!?) – same thing?

Just by way of a reference to how MIDI is hooked up for Squeak – for several platforms – take a peek at:-
http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/Cross/plugins/MIDIPlugin/MIDIPlugin.h?view=markup
http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/Mac%20OS/plugins/MIDIPlugin/sqMacMIDI.c?view=markup
http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/unix/plugins/MIDIPlugin/sqUnixMIDI.c?view=markup
http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/unix/plugins/MIDIPlugin/sqUnixMIDIALSA.inc?view=markup
http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/win32/plugins/MIDIPlugin/sqWin32MIDI.c?view=markup
Obviously quite a lot of that bunch will mean nothing to you but it might give a decent overview of how MIDI is used by other people. I often find compare & contrast an effective learning tool.

Rick:

950?! That’s a REM following the BGET#in%.

Yes, I was surprised at that.

Part of my motivation behind compiling MidiTest was to attempt to debug it.

DDT is, reasonably enough, ineffective again interpreted BASIC bugs :) So, I thought, compile it, then fire up DDT & see if that helps. Eventually I realised that DDT telling me there’s no ABC lib’s meant I also need to have !ABC sitting in the icon bar. That stopped that complaint.

However, MidiTest still crashed after displaying:

Identified device: USB3
Identified endpoint: 1
Identified endpoint: 1
Identified endpoint: 1
_

I’ll REM the MODE 28, recompile & run that so at least I can maybe see if any dramatic changes in the task window displayed memory allocation when it crashes, & incorporate your suggested changes.

Obviously my lack of knowledge yet regarding RISC OS isn’t helping, sorry about that.

At least with RISC OS, I don’t have to wait a fortnight for the thing to reboot :) I’ve set up a static IP now so it’s even quicker to get to the desktop.

it might give a decent overview of how MIDI is used by other people. I often find compare & contrast an effective learning tool.

IME, that strategy is essential.

Some years ago, we were trying to find a new trainer, an almost impossible task.
So, my Boss took this chap on whilst I was away. When I returned, new chap wandered into my office, scanned my extensive bookshelves & said “Why have you got all these Mips® & Hewlett Packard µP architecture books? I thought we just did MC68xxx, & PowerPC®”?

I realised straightaway this wasn’t going to last…..

Thank you for those references.

Try something = comment out the BGET and replace it with b% = 0 and run the program. Does it still crash, or is something going wrong with DeviceFS via the BGET call?
Can’t fathom why it works okay on the 256Mb Pi though.

Whatever it’s displaying scrolls up the screen too fast to see. I can press escape to get out of it though.

Just removed TRACE ON, so I can see that in fact the on screen display is exactly as my previous post, ending at the _ cursor. So yes, BGET area is looking promising?

You said you were going to test it on another 512Mb Pi (ummm, how many of them d’you have!?)

I bought another 512 to build a poor man’s Apple TV, or rather poor man’s Airplay. Its destination was at my Mum’s (no wifi, no internet, so adhoc essential) where it would be permanently plugged into Mum’s telly so that when my Sister visited she could show her any family photo’s she’d taken on her iPad sans Mum tripping up over thick video cables. The genuine article would have been best, but 90% of it would never be used, so at 1/3 the cost, the Pi was the best bet. As of 2 weeks ago, sadly it’s no longer necessary, & typical, just as the latest software release fixes the stuttering bugs that existed for hi-def films (Anime looks particularly good :-) )

Writing on phone while on break at work…

DDT is for debugging compiled programs. If you can read ARM, you’ll get some mileage there too. It is about as useful at dealings with BASIC as carrying runes to debug…

Go to BASIC and type HELP TRACE as there is form ( TRACE STEP ?) that will require you to press Space or something for each line. Tedious but effective.
If the fault is the BGET, this is promising for my program, but disturbing due to what that could signify…
I think I’ll need to roll this on the Beagle.

You could always try sticking a *spool miditestlog after a known good point to enable you to examine the trace output at your leisure.