USB MIDI?

DDT … is about as useful at dealings with BASIC as carrying runes to debug…

You may find Reporter considerably more useful for BASIC debugging!

In fact it’s been in use for the entire test period, & is indeed a useful tool, thank you Martin.

Andrew, spool sounds useful. Where would I find any resulting log please?

Well Andrew,

in fact your statement is very useful even though, if yet created, I don’t know where to find the log :)

Your *spool miditestlog placed after Rick’s first BGET statement causes the program to halt displaying (drum roll):

Endpoint in use

Press SPACE or click mouse to continue

But, more importantly the machine is still alive!

Martin,

Reporter tells me (Red background):

• WimpError ** from unknown task

“Endpoint in use” means it wasn’t closed when the programme exited previously. You need to consider two cases: normal exit and abnormal exit. For abnormal exit, there should be an error handler that closes all open endpoints (and files). I’ve found it useful to have a procedure to close each endpoint and each file (and to use ONLY the procedure), and an overall procedure to close them all. Make sure you handle possible errors within the close procedure!

I’ve tried to do this with all my USB apps, so you may find it useful to look at one or more of them. My website is http://davehigton.me.uk

Good to hear Reporter is some use. Instead of messing with TRACE ON and *Spool, you could try *ReportTrace.

*ReportDebug at the start of the program should give a stack trace of active PROC/FN/etc calls at the time of the error.

The WimpError is just saying it cannot find the task name (perhaps it has not been set yet?) and the most useful bits are the next lines which should give the error number and message.

“Endpoint in use” means it wasn’t closed when the programme exited previously.

Ok, makes sense. Any thoughts on why it seems to behave on the 256 meg’s Pi, but not 512?

Just looking at your site now, thank you.

you could try *ReportTrace.

*ReportDebug at the start of the program should give a stack trace of active PROC/FN/etc calls at the time of the error.

In fact it’s rather more comprehensive than at first apparent. Naturally I turned on RMA reporting BEFORE reading the warning :-) Dozens of Free & red Claim reports. I need to read & understand the naming conventions used in RISC OS. I imagine there’s a list of error codes somewhere, e.g.., Error : &11?

Endpoint in use

Have you altered the error handler? The second one closers the endpoint file…

It is a single tasking program, there is no task name (perhaps Reporter should pick up in the program name in this case?).

No.

Apart from reading the odd post, I’ve been splitting wood so that we don’t freeze to death :) It’s been hovering around (mostly below) 0º C for what seems like an eternity here. Even my brother in law who now lives near Toulouse is feeling the cold today. Generally, he’s had several degrees higher daily, sickening ;-)

This is quite an interesting thread, despite most of the stuff being beyond my understanding. I also have an E333 MIDI keyboard and thought it would be fun trying Rick’s programs on my pi (512M). Both miditest and midiplay work fine.

I added to the midiplay code creating a very basic play procedure. It plays whatever sequence of notes you like. There is only one octave of whole notes, but it was fun to do. The code is untidy, but I am neither a programmer nor an IT person. The code is here : http://www.lodelane.co.uk/files/playnotes.zip
Cheers,
Becky.

Both miditest and midiplay work fine.

Rebecca,

could you try escaping from miditest a few times & see what happens when you rerun it please, or have you already successfully tried that?

If I find my Atari synth’ s/w I’ll report back on your Play program.

It is a single tasking program, there is no task name (perhaps Reporter should pick up in the program name in this case?).

Single-tasking makes debugging an ‘after the event’ activity. Difficult unless you have a real-time debugger, and Reporter is very much a Wimp Task. Can you run the program under a TaskWindow?

If I knew how to find the program name, I would add it…

Rick,

only the *spool stops it crashing so far. Often the failure point is:

Endpoint in use at 870

Any significance in that number?

John,

miditest reruns with no problems here after escaping. Tried it five times.

Thank you Rebecca.

Both you & Rick are using the same keyboard. Mine’s an old “dumb” keyboard along with a USB to DIN adapter. I’ll lug my wife’s 88 key keyboard in later & try that. I suspect that also may work fine….

John,

Brittany here (somewhere between Rennes and Angers) and it isn’t helped that I work in a factory producing frozen food – so… yeah… G*d d**n it’s cold! :-(

I’m half pleased half displeased. What pleases me is Becky’s test on a 512Mb Pi seems to be working. I’ll try her program in a mo.

Oh, and “870” (or any other number) is the line number given by BASIC when the program stops. Ordinarily !Edit will not show these, but !Zap will. The thing is, an endpoint must be closed before it can be re-opened. It sounds like you may have altered the second ON ERROR statement. Just after the OPENIN line, it should say:

ON ERROR CLOSE#in% : SOUND 1,0,0,0 : PRINT REPORT$+" at "+STR$(ERL) : END

Now for what displeases me. Oh look, quirks in the USB stack.

With a Beagle, I can run “playtest” (opens output endpoint, GBPB’s four bytes, closes endpoint) and a middle C sounds on the keyboard.

However, miditest consistantly fails as reading data from an opened input endpoint does not work.

*BASIC
ARM BBC BASIC V version 1.53 (C) Acorn 1989

Starting with 512078076 bytes free

>i% = OPENIN("devices#endpoint2:USB11")
b% = BGET#i%

USB transfer failed: IO Error
>

I tried my original OMAP3 ROM from July last year, and I’m now running last night’s build. Same thing, same thing.

BGET fails, GBPB fails. The endpoint is correct (there are only two – 1=to keyboard (1 OUT Bulk 64 bytes 0 frames), 2=from keyboard (2 IN Bulk 64 bytes 0 frames)). I don’t understand why output is working but input not.

I’ll need to throw this one over to Jeffrey and various Steves to see if somebody more au fait with the original USB system can provide pointers or suggestions.
If it helps, EXT#i% returns zero regardless of whether or not any keys have been played. Not that that matters, the keyboard ought to be spitting Active Sense a couple of times per second, so there ought to be data…
Oh, and same result regardless of whether the keyboard is connected by the Belkin hub (as is the case with the Pi) or plugged directly into the Beagle.

USB transfer failed: IO Error

It looks like it is failing because the data is going missing someplace between the keyboard and my program…

>i% = OPENIN("devices#interrupt;size1024;endpoint2:USB11")
>SYS "DeviceFS_CallDevice", (1<<31)+2, "USB11", i% TO ,,,s%,f%
>PRINT s%, f%
     1023     1023
>

Huh?

it isn’t helped that I work in a factory producing frozen food – so… yeah… G*d d**n it’s cold! :-(

Ouch! I don’t envy you there. We’re on the Northants – Bucks border, & come September may be heading for Toulouse & get some cycling in along Canal du Midi. Oh yes, midi….

No I haven’t touched that ON ERROR line at all.

I’ve got that Axelson book so I’ll plod through it if only to learn more about USB, as I don’t have much more than end user experience with it. I have discovered that USB 3 cables can pump out some serious noise….

I’ll be very interested to see your progress & of course test anything you write.

Becky,

Add a line to END the program, like:

PROCPlay(......stuff......)

CLOSE#o%

END
DEFPROCPlay(notes$)

Also, you might want to consider a more accurate way of timing than sitting in an empty loop 900,000 times. ;-)
You may have come across REPEAT...UNTIL and if you couple this with TIME you can wait for a given length of time reliably (my Beagle is running at 1GHz, your Pi is something like 700MHz, so what I heard may has been about a quarter faster than you intended).

Instead of FOR i%=1 TO pause% : NEXT i%, try:

t% = TIME : REPEAT UNTIL ((t% + 4) < TIME)

Now it’ll sound the same no matter what sort of machine it is running on. TIME increments 100 times a second.

Just a thought – if you could write some code to pause without playing a note upon receiving a “-” character, you could use one or more “-”s to play a simple tune. ;-)

If I knew how to find the program name, I would add it…

Hmmm. BASIC allows you to give a program a name with this first line:

REM> Progname

In the original context this allowed you to save the program with just SAVE, and I think I recall that ARMBE and TWIN used it as well.

Error reporting from libraries uses this name.

Some parts of Basalt, eg THROW, DATA$, LINE and ORIGIN, use it, as does my Basil module for sharing libraries.

CRUNCH, and its automatic version, do not remove such a first line REM.

t% = TIME : REPEAT UNTIL ((t% + 4) < TIME)

I like this better for style:

t% = TIME+4 : REPEAT UNTIL TIME > t%)

But, as I am in plugging mode, Basalt has:

WAIT 4

;-)

But, as I am in plugging mode, Basalt has:
WAIT 4

Why not patch some of this stuff into the real BASIC module so it is available once and for all (on the newer releases, at least)?

Thanks Rick for your suggestions. I will have a play and see what happens.

Why not patch some of this stuff into the real BASIC module?

The reasons have been well rehearsed, but there are two fundamental ones.

First, backward compatibility. New features cannot be used on old machines as they stand, so programs will probably not use them.

Second, fixed addressing. New BASIC module versions cannot be softloaded over each other, so an application cannot RMEnsure the one it needs; cf the SCL.

The approach Basalt takes makes its features available in conjunction with all BASIC V modules up to now.

Without looking it up, I think Jonathan Hartson included WAIT n% in his NewBASIC(?) module a few years back.

Duplicate post removed