BBC BASIC
Development >> Raspberry Pi >> Irregular timing on RPi ?
http://bbcbasic.conforums.com/index.cgi?board=raspberry&action=display&num=1502902830
Irregular timing on RPi ?
Post by hitsware on Aug 16th, 2017, 5:00pm

Or is this part of the GL problem ?
Also: Why won't OSCLI work with the first statements ?
Code:
   SYS "system","sudo modprobe snd-virmidi snd_index=0"   SYS "system","aconnect 20:0 128:0"   REPEAT   FOR x=0 TO 1: READ b0,b1,b2   PROC_pmn(b0,b1,b2)   NEXT x:   RESTORE   WAIT 25   UNTIL FALSE   END   DEF PROC_pmn(b0,b1,b2)   OSCLI "amidi -p hw:1,0 -S'"+STR$~(b0)+""+STR$~(b1)+""+STR$~(b2)+"';"   ENDPROC   DATA 144,60,127, 176,123,0
Re: Irregular timing on RPi ?
Post by Richard Russell on Aug 16th, 2017, 6:47pm

on Aug 16th, 2017, 5:00pm, hitsware wrote:
Why won't OSCLI work with the first statements ?

Does it fail always or does it work successfully the first time? If it's the latter I expect it's because you are repeating the commands when they should only be issued once. With the SYS code (in which you are ignoring the return value) you don't notice the failure, but with OSCLI the failure matters.

Check the value returned from SYS, that should allow you to determine the reason for the failure by comparing it with what is documented here.

Richard.
Re: Irregular timing on RPi ?
Post by hitsware on Aug 16th, 2017, 8:22pm

> Check the value returned from SYS,

Where do I find that ?

I'm sure you're right though.
When I do those with Ruby, the first time I get nothing back,
but subsequently something like " connections already made"
Re: Irregular timing on RPi ?
Post by Richard Russell on Aug 16th, 2017, 9:37pm

on Aug 16th, 2017, 8:22pm, hitsware wrote:
Where do I find that ?

The syntax is:

Code:
      SYS "function", parameters... TO retval

As far as the irregular timing is concerned I don't think you'll ever be able to make it accurate by shelling out to 'amidi' - there's just too much overhead in calling a complex command-line tool.

A more satisfactory approach (and the way I was planning to do it in MIDILIB) is to write directly to the MIDI output stream:

Code:
      SYS "system","sudo modprobe snd-virmidi snd_index=0"      SYS "system","aconnect 20:0 128:0"      SYS "open", "/dev/midi1", 2, 0 TO hmidi%      IF hmidi% = -1 ERROR 100, "Failed to open MIDI output port"      REPEAT        FOR x=0 TO 1          READ b0,b1,b2          PROC_pmn(hmidi%,b0,b1,b2)        NEXT x        RESTORE        WAIT 25      UNTIL FALSE      END      DEF PROC_pmn(h%,b0,b1,b2)      LOCAL packet{}      DIM packet{0&,1&,2&}      packet.0& = b0      packet.1& = b1      packet.2& = b2      SYS "write", h%, packet{}, DIM(packet{})      ENDPROC      DATA 144,60,127, 176,123,0

The notes are played fairly regularly using this method, although I'm not keen on sending an 'all notes off' immediately after each one. Timidity seems sometimes not to play the note as a result, and I'm not at all surprised!

Richard.
Re: Irregular timing on RPi ?
Post by hitsware on Aug 16th, 2017, 11:29pm

GOOD ON YOU !
I use 'all notes off' to declude possible (@times) sticking notes
Any way to get something similar to this to work ...
It would be much more elegant:
Code:
    SYS "system","sudo modprobe snd-virmidi snd_index=0"    SYS "system","aconnect 20:0 128:0"    A=OPENOUT(/dev/midi1)REM: /dev/snd/midiC1D0 ???    REPEAT    PRINT#A"90 3C 7F"    PRINT#A"90 3C 0"    WAIT 25    UNTIL FALSE
Re: Irregular timing on RPi ?
Post by Richard Russell on Aug 17th, 2017, 09:10am

on Aug 16th, 2017, 11:29pm, hitsware wrote:
It would be much more elegant...

I disagree. As you no doubt know, I am very much not in favour of extending ('bloating', to use a more emotive term) an interpreted language when the same functionality can be achieved with a user-defined function or procedure, or in a library.

It would be helpful to have a MIDILIB library to provide platform-independent support for MIDI, but currently I have neither the time nor the expertise to tackle such a project.

Richard.
Re: Irregular timing on RPi ?
Post by hitsware on Aug 17th, 2017, 3:13pm

O.K.
I am obviously missing something basic.
If I connect an external usb midi synth to
say a Windows PC:
I open a serial com channel @ 31250 baud
and send messages of 3 bytes each.
The synth transforms the 3 bytes into the
full (3 byte)'message' initiating the event.
WHY cannot an internal soft-synth respond
to the same 3 bytes ? In fact one can hook
an external controller (sends the same
31250 baud messages INTO the PC)
and have the internal softsynth respond.
Again WHY can we not simply send the 3
bytes to the synth ? And I mean SIMPLY as
in writing to a file (especially in Linux) without
'libraries' et. al.......................
Re: Irregular timing on RPi ?
Post by Richard Russell on Aug 17th, 2017, 4:20pm

on Aug 17th, 2017, 3:13pm, hitsware wrote:
WHY can we not simply send the 3 bytes to the synth? And I mean SIMPLY as in writing to a file (especially in Linux) without 'libraries' et. al.

You can, and that's exactly what the code I listed does! It opens the file '/dev/midi1' and writes bytes to it, pure and simple. But that code is Linux-specific; other operating systems (Windows, Mac OS, Android etc.) do not implement MIDI the same way. For example in Windows a MIDI output device does not appear as a 'file' at all (you must call the midiOutOpen API).

Since BBCSDL is (supposed to be) a cross-platform version of BBC BASIC, for which you can write programs that will run without modification on all the supported platforms, that issue ideally needs to be resolved. The way to do so is to hive off the platform-specific MIDI code into a library, where the platform can be tested and the appropriate code used.

It's no different from the way I have managed to achieve compatibility between Windows, Linux/MacOS and Android in respect of 3D graphics. Under the hood the OSes use different, incompatible, subsystems: Direct3D in the case of Windows, OpenGL in the case of Linux/MacOS and OpenGLES in the case of Android. By 'hiding' the differences in a library (D3DLIB in the case of BB4W and OGLLIB for BBCSDL) the BBC BASIC programmer does not need to worry about which platform his code will be running on.

Richard.
Re: Irregular timing on RPi ?
Post by hitsware on Aug 17th, 2017, 4:39pm

Why doesn't OPENOUT work ?
(without the system call)
and other arcane stuff ..
Re: Irregular timing on RPi ?
Post by Richard Russell on Aug 17th, 2017, 5:48pm

on Aug 17th, 2017, 4:39pm, hitsware wrote:
Why doesn't OPENOUT work? (without the system call) and other arcane stuff

Assuming it doesn't (I've not tried) you'd have to ask that question at the SDL forum as it's in their domain, not mine (OPENOUT results in calling the SDL_RWFromFile function in SDL). Anyway I don't see that it matters. On most platforms, accessing a MIDI output device inevitably involves calling OS API functions, so SYS is unavoidable. The fact that on Linux 'everything' looks like a file, so in principle you might be able to avoid SYS, is a special case.

How would you go about programming MIDI output on an OS you are not familiar with? I'm guessing you would do exactly what I did: use Google to find an example! As is commonly the case the example I found was coded in C (or C++, I can't remember) so the simplest and most guaranteed way of getting it working in BBC BASIC was to translate that C code in the most obvious way. That's what I did, and it worked first time. Trying to avoid SYS would have been more work and less likely to succeed!

Richard.
Re: Irregular timing on RPi ?
Post by hitsware on Aug 17th, 2017, 6:11pm

> more work and less likely to succeed!

It's more than just the SDL.
Using other Basic's and Ruby I can write
to .txt files and (evedently(no errors back))
to /dev/midi1 or /dev/snd/C1D0 but no sound .....
If I have no success, the next 'Stretch' version
of Sonic-Pi supposedly will have a midi function.
And your routines are usable but we'll see
about the IDE. If I wanted the easy way I'd go
back to Windows, but am enchanted by the RPi smiley
Re: Irregular timing on RPi ?
Post by Richard Russell on Aug 17th, 2017, 6:40pm

on Aug 17th, 2017, 6:11pm, hitsware wrote:
Using other Basic's and Ruby I can write to .txt files..

I have explained on many occasions that it's only because of SDL that I was able to create a cross-platform version of BBC BASIC at all. Over the years I have often been asked to port BB4W to Linux or to Mac OS (etc.); I have consistently - and honestly - explained that it's not practical because, as an individual and with advancing years, I would never have been able to acquire the necessary level of understanding of those operating systems.

SDL - the Simple DirectMedia Layer - changed all that. Now, almost magically, I needed only to learn the (relatively simple) SDL API in order to create a working version of BBC BASIC for Linux, Mac OS, Android etc. But - and this is the crucial point - it is BBC BASIC for SDL 2.0 and not BBC BASIC for Linux or BBC BASIC for Mac OS or whatever.

It is therefore unfair to compare BBCSDL with Ruby or any other application which has almost certainly been developed specifically to run on Linux (and probably by a team of professional programmers). I expect that when you open an output file in Ruby etc. it is directly calling the Linux 'open' API - as the SYS call in my program does. So it's hardly surprising that you find you can successfully open a MIDI output 'file' in the same way. But, of course, BBCSDL doesn't call the native 'open' function it calls a function in SDL over which I have no control.

It's entirely your choice what application you end up using, but please don't criticise BBCSDL for being BBCSDL!

Quote:
If I have no success, the next 'Stretch' version of Sonic-Pi supposedly will have a midi function.

I can confirm that Raspbian Stretch has, sadly, not fixed the problem of the GL Driver breaking MIDI output. Not only that, but Stretch is even slower than Jessie if the GL Driver is not enabled - so slow in fact that BBCSDL is completely unusable. sad

Richard.
Re: Irregular timing on RPi ?
Post by hitsware on Aug 17th, 2017, 8:07pm


> Stretch is even slower than Jessie if the GL Driver is not enabled
> so slow in fact that BBCSDL is completely unusable.

Bummer undecided
Even with the GL enabled the IDE is not comfortable for me.
The snappiest Basic on RPi I've found is BWBasic which runs
in the terminal ........
Which reminds me ........... Is there any way to enlarge the
font with Brandy ? ? I'd like to try that, but the print is so small,
as to be (for me) almost unreadable.
Re: Irregular timing on RPi ?
Post by Richard Russell on Aug 17th, 2017, 8:22pm

on Aug 17th, 2017, 8:07pm, hitsware wrote:
Even with the GL enabled the IDE is not comfortable for me.

Is this on a Raspberry Pi 3 (I asked once before but you didn't answer)? On my RPi3 with the GL Driver enabled I haven't noticed any significant delays; the most important thing is that it can keep up with typing speed and that's certainly true here (but I'm not a touch typist).

Is there a specific action that you feel is slower than would be desirable? There may be little I can do, but I'm happy to have a look at the BASIC code (so could you, of course).

Richard.

Edit: For my own satisfaction I've just repeated the test. Here is the setup:
Everything I tried, bar one, responded subjectively 'instantaneously' (I haven't tried to quantify it, but perhaps in less than 0.1 seconds). The exception was the 'File... Compare...' selection, which is slow at the best of times (on all platforms) because comparing two programs and displaying the differences is hard.
Re: Irregular timing on RPi ?
Post by hitsware on Aug 18th, 2017, 02:48am

> Raspberry Pi 3
Mine 3-B (FWIW?)
> Raspbian Stretch
Just got that this afternoon
> VC4 GL Driver fully enabled
I'll do that (for the experiment)

Download url ?
I'll try to clone your install.
(I can't believe it would be so bad
(or would our perceptions be that
different))
Re: Irregular timing on RPi ?
Post by Richard Russell on Aug 18th, 2017, 08:49am

OK, progress. The claim that enabling the 'GL Driver' stops MIDI output working is false! What is actually happening is that enabling the GL driver creates a new sound 'card' called vc4hdmi which you can see by executing the following command in a terminal:

Code:
cat /proc/asound/cards

Obviously, the creation of this new card means that the Virtual MIDI card you attempt to create using modprobe cannot use slot 1 - because that is now occupied - but needs to go at slot 2. In general, you need to know what sound card slots are already occupied before you can issue this command. Once this is appreciated MIDI output works perfectly with the GL Driver enabled (and thus BBC BASIC responding quickly).

Annoyingly I even reported the supposed GL Driver 'fault' at the Raspberry Pi forum. I should have been more sceptical from the beginning, since it was never plausible that it could have this effect. I suspect it was a case of copying code found on the web 'by rote' without actually understanding how it works - one of my pet hates! If and when I get around to writing a MIDI library I will attempt to make it adapt to what has gone before, for example whether the GL Driver is enabled or not.

Richard.
Re: Irregular timing on RPi ?
Post by hitsware on Aug 18th, 2017, 2:55pm

> I suspect it was a case of copying code
> found on the web 'by rote' without actually
> understanding how it works -
> one of my pet hates!

I hate it too but must do it often to achieve my objective.
For instance: Back with BBC4W everytime I wanted to do
Midi I had to copy and paste your midi setup routine without
an iota of understanding. I hated it but with my limited
knowledge (and aptitude) for computers had no choice.
And I continue to find myself in those situations.
Re: Irregular timing on RPi ?
Post by Richard Russell on Aug 18th, 2017, 4:15pm

on Aug 18th, 2017, 2:55pm, hitsware wrote:
I had to copy and paste your midi setup routine without an iota of understanding.

You could have looked up the Windows API functions it uses at MSDN, where everything would have been explained in great detail. It's sometimes a little harder to do the same for Linux API functions, because there isn't one central reference in the same way, but nevertheless Google will usually find it.

There is no reason at all not to understand code you are using, given the wealth of resources on the internet and the search engines that are so good at finding things. Two days ago I knew literally nothing at all about MIDI on Linux, but Google found everything I needed to know, and at no point did I find myself having to copy code that I didn't understand.

The most useful reference I found was here. It explains about the card index - which is how I discovered your mistake - device numbers and routing. It has allowed me to write BBC BASIC code (which will hopefully eventually go into MIDILIB) which is entirely self-contained - no need to issue commands in a terminal for example - and runs correctly whatever the pre-existing system configuration, whether timidity has already been run or not etc.

Richard.
Re: Irregular timing on RPi ?
Post by hitsware on Aug 18th, 2017, 6:30pm

You grossly underestimate my inaptitude ...... undecided