SyntaxBomb - Indie Coders

I manually defined "#define __LINUX_ALSA__ 1" in RtMidi.cpp so it compiles in the ALSA api here on linux.

./bmk makeapp -g x64 -t console -r -x "/home/ronny/Arbeit/Tools/BlitzMaxNG/mod/bah.mod/rtmidi.mod/examples/midi_in.bmx"
[ 25%] Processing:midi_in.bmx
[100%] Linking:midi_in
  Input port #0 : Midi Through:Midi Through Port-0 14:0
Opening Midi Through:Midi Through Port-0 14:0
Reading MIDI from port ... quit with ESCAPE.
MidiInAlsa::openPort: a valid connection already exists!

The "printf" I added, report "OK" .. so opening the port was ok (here!) - dunno if it should work without anything connected. Guess so.


Think you should raise the issue in the bah.mod repository too ... and maybe add a link to the thread here. Brucey might then just update the module and fix potential issues he comes across doing so.


Anyways "opening" is something different than "reading" - so you might check "reading" too (not just "opening").

bye
Ron

Regarding "isPortOpen" ...

Docs

QuoteReturns true if a port is open and false if not.

Note that this only applies to connections made with the openPort() function, not to virtual ports.

Implemented in RtMidiOut, and RtMidiIn.

So it only returns True if the connection was made in your application (via openPort() _not_ if some other programme uses the devices.

It simply returns either 0 (virtual ports) or the value of "connected". Means it does not ask any hardware or driver ... it simply returns a value it set itself:
  inline bool isPortOpen() const { return connected_; }

void MidiInCore :: openPort( unsigned int portNumber, const std::string &portName )
{
...
  // Save our api-specific port information.
  data->port = port;

  connected_ = true;
}

bye
Ron

I tried anyway i can imagine to detect if the port used.. and in vain. .

when you do getportcount its still gives you the number

and when you ask MidiIn.isPortOpen it gives you zero in both cases ..

the thing is that it crashes the app.. or i could have live with that


other than that .. Midi Master and Derron..  here is a link for download
feel free to test it
im sure youll have lots of remarks

https://drive.google.com/file/d/1j7ddB53Me7QoK_Wk6KhiaANAULq8pe-U/view?usp=sharing

I can say i kinda finished it for this point..
im not sure when ill publish it..
but im very pleased from the point i come..

from this point forwards ill decide what i wanna do.
but thats how i work..  I dont finish things 100% 
unless I really want to

and thanks to Derron i started carrying about the looks of my apps.
up till now i didnt care much and it was a mistake

im sure you will find bugs or errors in the note detections and so on..
and i didnt put all the chords yet or the most common ones
and i already fix certain things since this last release.

p.s
i didnt had such a great day. i mean it was ok day but something went wrong.
so im a bit unbalanced atm
so it also effects my replies quality

I received this answer from Gary:

QuoteDo I understand it right: You have an existing MIDI Port on your system and want to read that MIDI stream with RtMidi. This doesn't work because the device is in use. This probably implies that you are using Windows as other systems usually have an intermediate layer that duplicates the stream to both applications. Both MacOS and ALSA have a device based API that allows exclusive access to the devices but usually the midi daemon (MacOS) or the sequencer API (ALSA) are used if exclusive access is necessary.
Whenever a port is not available while RtMidi tries to connect to it, an eception will be thrown. You should ask the BlitzMax people how to catch it.

Quote...when you do getportcount its still gives you the number

That is correct. The RT-MIDI reports the devices it finds, no matter whether they are already used or not working.

Quote...and when you ask MidiIn.isPortOpen it gives you zero in both cases ..

In both cases? What do you mean? And... a MIDI-Device is only open when you have opened it from blitzmax. So this is a command line that can only follow after your  Midi.MidiIn.openPort(n) 
 

Quotethe thing is that it crashes the app..

When? Which code line? Did you read about the Exceptions?

QuoteI can say i kinda finished it for this point..

Does this mean, you are not longer interesed in solving this problem?

Quotep.s
i didnt had such a great day. i mean it was ok day but something went wrong.
so im a bit unbalanced atm

Keep on struggling! We know, how you suffer. Have a brake for today... There is always a tomorrow!

sure im interested in solving the problem lol..   I meant ive reached the point i wanted in this project,
lets compare It to mountain climbing.. ive reached the peek and now the descending is the same way.. but much easier ..
all im saying is that i can lower the intensity of dealing with this project.

But the whole Idea of Frameworking is that all problems must be solve so the system will work properly..
I need to solve this problem for future programs not only this one..
so how can i be not interested. :p

Quote...and when you ask MidiIn.isPortOpen it gives you zero in both cases ..

I meant that when i ask midiin.isportopen() when some external app is using the midi.. or when it doesnt 
it give same result which is 0.
anyway.. no way to detect if midi is busy unless theirs an external method to do it..

also one more thing. if i turn off my synthesizer.. the app crashes if i try to play.. 
because it seeks the port and it does not exist..
so this should be solved too.

im facing lots of issues.. and i thing there might be an issue with openal and windows 11 as well..
but i need to make more tests..

if you have a chance please check if my program runs on your computer..
it may be missing some image files.. 
but on my friends computer it somehow workd 

Please check what happens, when you doing this:

1. Close all other MIDI-apps
2. Switch on your synthi
3. In your code: create a RTMidiIn instance
3. Open the port to your synthi device
4. Play something on the synthi
5. As a proof print the data protocol to the screen
5. Now check MidiIn.IsPortOpen()

Does it really now report "0"

I made an arpagio chord player and for some reason when i press a chord button.
each time the first note does not play in the right bit.. either its too long or too short in like 50MS

MM... you gave a sync example that does not work. there is not Clear command in MidiIn.

IsPortOn() does return True when I use the synth..
whether I truned it before or after..

the IsPortOncannot check external use of midi.. so it seems. and theirs where the problem lies.

if instead of crashing the app it would just return error message all would be solved.



if i turn off my synth and i try to play midi out to the synth. the midi gives error and crashes..
and no way to detect this either

The way MidiIn.IsPortOpen()  is working is correct. It only checks if YOU opened a port before. You cannot use it for ports you did not open!!!

The central point is the MidiIn.OpenPort(). Here you can find out if BlitzMax was able to open the port. If another app already uses this port the function MidiIn.OpenPort()  returns a error message in form of an exception. You need to be prepared to receive such an exception, otherwise the OS will "handle" the exception and react with stopping your app. That is what you see as "crash".

The exceptions are handled in a Try/Catch-Block

We (Deron and me) are not 100% sure, wether this would work, but test this:

(Hy Deron, did you read that LINUX instead of WINDOWS allowes to open the same port from different apps?)

...
If PortsExists_flg
    Try
        Midi.MidiIn.openPort(0)
    Catch Exception:Object
        Print "Device open failed:"
        Print Exception.ToString()
    End Try
   
EndIf

Ok i get it ill try this. 
I never used try catch thing 
It's new to me 

The code @Midimaster wrote should work.

"IsOpenPort()" returns what inside of rtMidi is stored in "connected_". This variable is set to "true" once "OpenPort()" finished executing their internal stuff without erroring out.

If stuff errors out, rtMidi prints to the console/terminal/stdiout... that xyz is not OK. It additionally throws an exception with a similar error message.

Bruceys rtMidi.mod fetches these exceptions - and throws it's own "Blitzmax compatible exception".

Inside the module the OpenPort() method does not return any result. So you cannot do 
If Not MidiIn.OpenPort(0) then ...

You must - for now - do as Midimaster suggested: wrap it in try-catch.

bye
Ron

Ok... I have made some test with my equipment.

If I connect my NORD ELECTRO 6 to the computer and start the corresponding NORD SOUND MANAGER app, they can exchange informations. When I now start my SCORETRAINER app, it is possible to use this MIDI-IN and MIDI-OUT port also from SCORETRAINER parallel.

If I connect my NORD ELECTRO 6 to the computer and start the MIDI-OX app, they can exchange informations, but.... When I now start my SCORETRAINER app, my app crashes, when trying to use this port too.

If I connect my NORD ELECTRO 6 to the computer and start the my SCORETRAINER app first, they can exchange informations, but.... When I now start the MIDI-OX app, MIDI-OX reports that the device is already in use and does not open the device.

So it depend on the software you use. Nevertheless my own software should be prepaired for situations where the device I want to connect is not avaiable. So I will also add the TRY/CATCH way to my MIDI-Class.

Ok. ive managed to catch the Error.. and inform the user of the problem.
But I cant still make it so that the app will keep running.. regardless..
but its a major progress. so at least the user will be aware of the problem

so up till today no one explained me well what this try and catch actually does..
and i did ask..

but anyway.. theirs some holes in my knowledge concerning blitz..
like for example .. i never created an event and i have no idea what exactly that is
and what it is good for

The Try/Catch way prevents the app from crashing. If a error occurs and the system is able to "throw" an exception, you have the chance of reacting to this message. In this case the action you tried ("open the port") will be canceled and the app will continue and not crash.

I added this feature today to my MIDI-Class and now the app does not longer crash if a second app already uses the port I want to open.

Also your app should now continue! Of course you cannot use the port afterwards. It is not open!

In the CATCH-part you could set your variable PortExists_flg=False and later you can check this before sending anything.

Quote from: Hardcoal on April 03, 2023, 19:10:38so up till today no one explained me well what this try and catch actually does..
and i did ask..

There is always the option to ... simply use a search engine of your choice. I bet it will come up with explanations even in your mother tongue.

Do not let us explain you everything!


bye
Ron