Support for midi output using ALSA #62
Conversation
|
This looks cool. But there are a few problems. This mixes tab characters into the source code. It also includes non-English comments and text. It also makes some stealthy edits and changes that it shouldn't. You change the target arch from nehalem to native, ignoring the detailed and important comment above but also leaving the comment in place, making it a contradictory comment. And you don't mention this change anywhere or provide a justification for it. But it does a good job of following the existing orca-c code and adding the ALSA MIDI feature in an appropriate way. I'm not sure I want to add this to the Hundredrabbits orca-c right now, but I encourage you to keep your own fork of it with these changes. I don't have any way to test this myself. I could be convinced otherwise if other people think it would be a good idea, though. |
|
I thinks this will be a nice thing to have, as there is not that much code added and it could be good to have an alternative to portmidi. The commit surely need some cleaning, due to the fact that are included two commits that would have required different PR. The commit for fixing the linking error in @caropf machine introduces a linking error on mine, as i don't have the The commit for the ALSA output needs some casting ( output of tui_main.c: In function ‘send_midi_3bytes’:
tui_main.c:1041:2: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
snd_seq_ev_set_source(&ev, midi_mode->alsa.port_id);
^~~~~~~~~~~~~~~~~~~~~
tui_main.c:1047:3: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
snd_seq_ev_schedule_tick(&ev, SND_SEQ_QUEUE_DIRECT, 1, 0);
^~~~~~~~~~~~~~~~~~~~~~~~
tui_main.c:1051:3: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
snd_seq_ev_schedule_tick(&ev, SND_SEQ_QUEUE_DIRECT, 1, 0);
^~~~~~~~~~~~~~~~~~~~~~~~
tui_main.c:1055:3: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
snd_seq_ev_schedule_tick(&ev, SND_SEQ_QUEUE_DIRECT, 1, 0);
^~~~~~~~~~~~~~~~~~~~~~~~
tui_main.c:1059:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
case 0x8: snd_seq_ev_set_noteoff(&ev, channel, byte1, byte2); break;
^~~~~~~~~~~~~~~~~~~~~~
tui_main.c:1059:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
tui_main.c:1059:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
tui_main.c:1059:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
tui_main.c:1060:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
case 0x9: snd_seq_ev_set_noteon(&ev, channel, byte1, byte2); break;
^~~~~~~~~~~~~~~~~~~~~
tui_main.c:1060:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
tui_main.c:1060:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
tui_main.c:1060:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
tui_main.c:1061:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
case 0xb: snd_seq_ev_set_controller(&ev, channel, byte1, byte2); break;
^~~~~~~~~~~~~~~~~~~~~~~~~
tui_main.c:1061:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
tui_main.c:1061:15: warning: conversion to ‘unsigned int’ from ‘int’ may change the sign of the result [-Wsign-conversion]
tui_main.c:1062:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]
case 0xe: snd_seq_ev_set_pitchbend(&ev, channel, (byte2<<8) | byte1); break;
^~~~~~~~~~~~~~~~~~~~~~~~
tui_main.c:1062:15: warning: conversion from ‘int’ to ‘unsigned char’ may change value [-Wconversion]i fired up VCV Rack to do some testing and it worked fine, it's nice to see ORCA listed as Also the |
Sorry, I forgot to revert the target arch back to nehalem before commiting. About the other points you mentioned, I can fix them and the conversion warnings mentioned by @npisanti.
It seems each distro handles tinfo their own way. Gentoo installs both libtinfo.so and libtinfow.so, with the latter being installed only if unicode is enabled when compiling ncurses, while on debian it seems libtinfo installs libtinfo.so only. Maybe a solution is to check if libtinfow is installed before deciding if linking against it is (possibly) necessary. |
|
I am attempting to use this as I do not have java on my system and as far as I can tell you can't build portmidi without java. However it does not have any sound what so ever for me. |
|
Most distros have a version of PortMidi with the Java build configuration system stripped out, I think. Also PortMidi sends MIDI messages. MIDI is not audio. It doesn't make any sound. |
also fixes #61