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 :-)