hi there,

so i stumbled across the fact that a bela that is connected to a computer via usb actually shows up as a midi device called BELA (in Ableton, PD etc.)

what is up with that? can i send messages from a pd/heavy project to this port? how is it addressed?

you can. It's port hw:0,0,0 (as you can see from running amidi -l to list all the devices.
Using it with Heavy/Pd should be straightforward. as you can see from the 08-PureData/hello-midi example:

alt text

    giuliomoro

    hmm, unfortunately this does not seem to work with heavy. here is an example that works with libpd, but i guess with heavy we hit the same problem as by multiple midi ports input. heavy does not allow channels greater then 16. on input side this is not so bad, since we simply get them mirrored down to the first 16 channels, but on output we never reach the second port.

    this is my example:

    #N canvas 113 106 450 300 10;
#X obj 125 31 metro 1000;
#X obj 238 38 f;
#X obj 245 70 select 127;
#X obj 269 38 + 1;
#X msg 245 10 0;
#X obj 49 8 loadbang;
#X obj 129 7 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 15 114 send bela_setMidi @hv_param;
#X msg 15 87 hw 0 0 0;
#X obj 75 48 delay 2000;
#X obj 229 256 ctlout;
#X obj 239 208 unpack f f f;
#X msg 235 172 \$1 20 18;
#X connect 0 0 1 0;
#X connect 1 0 3 0;
#X connect 1 0 2 0;
#X connect 1 0 12 0;
#X connect 2 0 4 0;
#X connect 3 0 1 1;
#X connect 4 0 1 1;
#X connect 5 0 8 0;
#X connect 5 0 9 0;
#X connect 6 0 0 0;
#X connect 8 0 7 0;
#X connect 9 0 0 0;
#X connect 11 0 10 0;
#X connect 11 1 10 1;
#X connect 11 2 10 2;
#X connect 12 0 11 0;

    any ideas?

      hmm I had a look and it seems a problem with hvcc (also there was some issue with the Bela code).
      Here is the Bela fix, and here is the hvcc one.
      Here is your fix for multiple midi in ports, I think.

      I have merged the branch I made for you a while ago (to support multiple MIDI interfaces on heavy) into dev, so you should be able to simply upgrade your board to the latest dev branch and have all the above fixed for you.

        giuliomoro thanks!

        i will still need to download hvcc separately, right? that would be the master-midi branch then?

          ok, well:

          after i upgraded the bela version with the update board script i tried to compile my patch, here are my findings:

          when no midi device is connected the heavyprogram outputs midi on the virtual midi device, of course if i select channel 18 (as in my example) it is restricted to channel 16.

          if i connect a midi device to the host port (and therefore hw: 0.0.0 becomes the second midi port, addressed by channel 17-32) things do not work anymore. there is no midi output on the virtual midi port.

          as i stated earlier this most likely is a heavy problem since also on midi input, channels above 16 do not work. so for the output case, there is no way to "select" the second midi port, since heavy simply does not recognise channels above 16. hmm...

          i then tried my example with the IDE and libpd again and i now get the following error (after updating)

          Segmentation fault
make: *** [runide] Error 139

          this happens on all pd projects that i try on the board.

          just for clarification, i also tried to send the message on channel 2, assuming that heavy would then just send on all ports that are enabled, but nope, does not work :-(

            lokki as i stated earlier this most likely is a heavy problem since also on midi input, channels above 16 do not work.

            I tested the new code I wrote for you last night, from the dev branch, and they do indeed work. Did you update to the dev branch? https://github.com/BelaPlatform/Bela/issues/501

            lokki i then tried my example with the IDE and libpd again and i now get the following error (after updating)

            Segmentation fault
            make: *** [runide] Error 139

            Extremely sad. I think this happens when the core code is compiled with gcc I think (which is used by heavy as default, so you should only have this problem if the first project you build after updating the board is a heavy project). It should be this issue here: https://github.com/BelaPlatform/Bela/issues/501

            You should be able to fix this with make -C ~/Bela coreclean lib. This will rebuild the core code with clang.

                well i downloaded from the dev branch, and got a Bela-dev zip that i extracted and run update-board from, so pretty sure yes, but will recheck.

                so you had a midi device on the host port and you were able to send messages to the virtual midi port? as stated, with just the virtual port it works...

                what example did you use?

                thanks for all the help, will try the recompiling this evening

                btw, i am still on

                Bela image, v0.3.5b, 24 July 2018

                but that should not be the issue, right?

                recompiling helped with the libpd issue, thanks!

                i uncommented the rt_printf line to see what is sent by heavy:

                case 0xe5e2a040: { // __hv_ctlout
			if (!hv_msg_hasFormat(m, "fff")) return;
			midi_byte_t value = (midi_byte_t) hv_msg_getFloat(m, 0);
			midi_byte_t controller = (midi_byte_t) hv_msg_getFloat(m, 1);
			int channel = (midi_byte_t) hv_msg_getFloat(m, 2);
			int port = getPortChannel(&channel);
			rt_printf("controlout[%d]: %d %d %d\n", port, channel, controller, value);
			midi[port]->writeControlChange(channel, controller, value);
			break;
		}

                and if i set the channel above 16, it always sends on channel 15 (zero based). so i guess i somehow did something wrong...i really downloaded from dev though...

                right. so what I tested was the inputs not the outputs. Now I did and indeed it was another problem with Heavy, e.g.:

                interpreters/pd2hv/libs/pd/noteout.pd

                alt text

                The input range was being clipped (sometimes to 0-16, sometimes to 0-15). I pushed another fix for hvcc: https://github.com/giuliomoro/hvcc/tree/master-midi

                Fixing heavy issues is not so hard after all!

                ah now i get it! that means i can also just directly use the __hv_ctlout @hv_param instead of ctlout. thanks will test asap!

                ok, fixed all the midi out objects on my computer, rather then redownloading. and, it works! yes. nice! thanks for your time and support. was not thinking that it would be that easy to fix it.

                ok, my "nifty" idea went downhill :-)

                i wanted to connect the bela to the usb-host of an axoloti and read the midi data from the bela into the axoloti. but it seems the bela is not recognised by the axoloti as a midi capable device (presumably because it has many more functions on the usb-port, not just midi).

                oh well, at least you/we fixed the midi output and input of heavy objects :-)

                EDIT: found and old usb-hub, to the usb-host of the bela, connected the axoloti and my qunexus there and voila, they communicate :-)

                nice, and since there are a couple of nice OLED objects for the axoloti i think i am going to use them, instead of tinkering with the i2c on the bela. that way, maybe i can make some music again in a couple of weeks :-)

                  4 months later

                  lokki i wanted to connect the bela to the usb-host of an axoloti and read the midi data from the bela into the axoloti. but it seems the bela is not recognised by the axoloti as a midi capable device (presumably because it has many more functions on the usb-port, not just midi).

                  hmm you could try disabling the extra devices on Bela, or changing the order in which they are created.
                  Notes:
                  1- if you are on Windows, changing the order will stop the USB-ethernet from working (Windows expects the ethernet to be the first device).
                  2- if changing the order does not work and you disable the other functions instead, you may lock yourself out of the board via USB, but you will still be able to access it through ethernet, or UART serial via an FTDI cable. Make sure you test one (or both) of these options as a fallback before you mess around with the below!

                  So how to do it:
                  on the board, edit /opt/Bela/bela_gadget.sh (currently, it should look like this).
                  Towards the bottom, it should look like:

                  ln -s functions/rndis.usb0 configs/c.1/ # this needs to be loaded first in order to work on Windows
ln -s functions/ecm.usb0 configs/c.1/
ln -s functions/mass_storage.0 configs/c.1/
ln -s functions/acm.usb0   configs/c.1/
ln -s functions/midi.usb0 configs/c.1

                  Change the order and/or remove devices as you see fit. The description of which is which is earlier in the file:

                  mkdir -p functions/rndis.usb0           # network, Windows compatible
mkdir -p functions/ecm.usb0             # network, macOS compatible
mkdir -p functions/mass_storage.0       # boot partition
mkdir -p functions/acm.usb0             # serial
mkdir -p functions/midi.usb0            # MIDI

                  My guess would be that if you disable mass_storage and acm (serial), and place midi at the first place, it may work.

                    thanks, i found another solution in the meantime, but i will play with this after i used the setup for a theatre project coming up in june :-) until then it stays how it is now, working :-)