agraef
commented
5 years ago Not sure what's up with that "Codacity" thingy, it seems to be stuck.
Closed agraef closed 5 years ago
agraef
commented
5 years ago Not sure what's up with that "Codacity" thingy, it seems to be stuck.
agraef
commented
5 years ago Noticed a few more potential issues in the MIDI part, please let me quickly augment the PR.
agraef
commented
5 years ago Ok, this should be in pretty good shape now. At least I haven't seen any more random crashes in MIDI input since I changed that to use the proper MIDI decoder object. ;-) (It was using the encoder before, which surely was a copy-and-paste blunder, but will of course give rise to race conditions if a ctlra app tries to do MIDI input and output at the same time. This might well have caused the sporadic segfaults I saw during stress testing with Ardour.)
agraef
commented
5 years ago No dice, I'm still getting these segfaults every once in a while, always in snd_midi_event_decode. :( Here's the gdb backtrace, in case you can make any sense of it.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f857b287c07 in __memmove_avx_unaligned_erms ()
from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7f85787f3d80 (LWP 3602))]
(gdb) bt
#0 0x00007f857b287c07 in __memmove_avx_unaligned_erms ()
from /usr/lib/libc.so.6
#1 0x00007f857ac33b32 in snd_midi_event_decode () from /usr/lib/libasound.so.2
#2 0x00007f857b802e39 in ctlra_midi_input_poll (s=0x55ce52d90590)
at ../ctlra/midi.c:150
#3 0x000055ce52ac9441 in daemon_feedback_func (dev=0x7f8577f71010,
d=0x55ce52da6040) at ../examples/daemon/daemon.c:112
#4 0x00007f857b7fd379 in ctlra_idle_iter (ctlra=0x55ce52d7abe0)
at ../ctlra/ctlra.c:478
#5 0x000055ce52acb804 in main (argc=2, argv=0x7ffd2e894ff8)
at ../examples/daemon/daemon.c:740The code of my daemon version is here: https://github.com/agraef/openAV-Ctlra/blob/mapping_v1-ag/examples/daemon/daemon.c. I'm calling ctlra_midi_input_poll from the program's feedback_func, is that the right way to do it? (I guess so, because I don't see any other callback that might be suitable.)
I don't see anything in midi.c that's obviously wrong any more. One thing I'm trying now is to move the call to snd_midi_event_init into ctlra_midi_input_poll so that the decoder gets reinitialized each time a message is decoded. This has been running without a single segfault for about 30 mins now, so I'm keeping my fingers crossed. :) Will commit this as soon as I've done some more testing tomorrow.
--- a/ctlra/midi.c
+++ b/ctlra/midi.c
@@ -81,7 +81,6 @@ struct ctlra_midi_t *ctlra_midi_open(const char *name,
if (res < 0)
printf("%s: error creating decoder\n", __func__);
snd_midi_event_no_status(m->decoder, 1);
- snd_midi_event_init(m->decoder);
/* Keep callback / ud */
m->input_cb = cb;
@@ -147,6 +146,7 @@ int ctlra_midi_input_poll(struct ctlra_midi_t *s)
continue;
}
+ snd_midi_event_init(s->decoder);
nbytes = snd_midi_event_decode(s->decoder, buffer, MAX_MSG_SIZE, seq_ev);
if (nbytes <= 0) {
// reinitialize the decoder, to be on the safe sideNope, it just crashed again. :(( I'm beginning to suspect that Ardour on occasion spews out some random garbage on its mackie_output port which makes the ALSA MIDI decoder go bonkers. Or maybe it's an issue with the ALSA-Jack MIDI bridge.
What I noticed is that the controls on my Behringer X-Touch, which is connected to the same port, went dead pretty much in the same instant that ctlra_daemon segfaulted, so there is something strange going on there. But of course snd_midi_event_decode should never segfault, even when receiving random garbage, as long as its buffer argument is ok (which it is, it's an array local to ctlra_midi_input_poll, and the proper buffer size is passed as well).
Anyway, I think that my changes to midi.c are sound, so this PR should be ready to go in. And if you happen to have an idea why the ALSA decoder likes crashing on MCP sysex data from Ardour so much, please let me know. :)
agraef
commented
5 years ago Oops, I just noticed that I accidentally had Jack2's internal ALSA MIDI bridge running alongside a2jmidid. Maybe that wasn't such a great idea. ;-) I don't think that this would do any harm, but I'm testing again now to see whether running without the internal bridge gets rid of those segfaults.
agraef
commented
5 years ago Nope, still crashes. I'm stumped. Maybe an ALSA bug? (Unlikely, I know.)
agraef
commented
5 years ago The saga of the wild MIDI input crashes continues. :)
I pretty much nailed this down now. It appears that every so often, snd_seq_event_input() returns a sysex event struct that looks all right at first glance (even has the right length of the sysex message), but the external data pointer that goes along with it (seq_ev->data.ext.ptr) is bogus (it's always something like 0xffffab...). Now I could check for those rogue pointer values beforehand, but that seems like an awful kludge. Still, I might end up doing this, if the bug persists after the next ALSA update. (And no, I won't go into debugging ALSA itself, at least not when I'm on vacation. ;-)
However, one more suspicious thing in the midi.c code that I noticed is that there's a call to snd_seq_event_input_pending() right after the call to snd_seq_event_input() and before the call to snd_midi_event_decode(). My gut feeling is that this might be an issue if snd_seq_event_input_pending() pulls new data from the internal ALSA buffers before the event has been parsed, thereby possibly invalidating the data of the event just read. It's just a wild guess, but one thing that I can try is to move that call after the call to snd_midi_event_decode() and see whether that helps. To me this seems to be the right thing anyway.
agraef
commented
5 years ago That was it, apparently. Well, at least it's now been running for over two hours without crashing. Will commit this change in a minute.
agraef
commented
5 years ago Just committed another bugfix to the Mk3 backend (some buttons would also trigger the pedal, so we must check for the specific bit mask of the latter).
agraef
commented
5 years ago This "Top 8" button really sticks out like a sore thumb. It's just in the wrong position. I don't think that putting it in the right position, just after "Top 7", would hurt. Never mind that it's actually at byte offset 1 instead of 9 where the other top buttons are, they probably just used some extra bit there to save an extra byte. But we don't have to follow that mad layout in the numbering of the buttons.
Let me quickly fix that as well.
agraef
commented
5 years ago Ok, there you go. "Top 8" comes after "Top 7" now, and "A" after "Shift", as one would expect.
Note that this will break existing mappings for the MK3 (I have to rework mine as well), since the buttons between "A" and "Top 8" have different numbers now. But I'd say that it's a price worth paying for making the button layout sane. Better do it now than never. This backend code may well show up in some ALSA driver for the Mk3 some day, and then we want to have "Top 8" in the right place, don't we? ;-)
What are your thoughts? The previous layout with the "Top 8" in the wrong place annoys me to no end, but if you're really worried about backward compatibility at this point already, just get rid of the last commit in this PR, it's your choice.
BTW, there's one more outbreak of sudden madness in the order of the buttons, namely that the encoder touches are listed in reverse order, so "Encoder Touch 1" comes last. But that's not nearly as bad, since at least they're consecutive, and probably not used as much in applications as the top buttons anyway.
Hmm, thinking about this some more, if we are going to break things anyway, then we might just as well fix the reverse encoder touch order as well. :) One more commit underway, stay tuned...
agraef
commented
5 years ago Ok, there you go again. This should be in pretty good shape now. Awaiting your comments...
agraef
commented
5 years ago In case you don't have the time to read through all the comments above, here's the executive summary of the PR as it stands now:
midi.c:
Enlarged buffer sizes to make sysex input work.
Fixed occasional crashes in MIDI input when receiving sysex.
ni_maschine_mk3.c:
Fixed some glitches in some of the table entries. In particular, transposed some of the tables entries to sanitize the order of button ids: the "Top 8" button now actually comes after "Top 7" and the encoder touch events are in the right (ascending) order.
Got rid of some spurious encoder events at initialization time.
Got rid of pedal events being mixed up with button events.
I've tested all of this quite extensively with my improved version of the daemon program at https://github.com/agraef/openAV-Ctlra/blob/mapping_v1-ag/examples/daemon/daemon.c connected to Ardour's Mackie input and output ports. With some trivial remapping of the buttons and encoders (https://github.com/agraef/midizap/blob/master/examples/Maschine.midizaprc), I can use the Mk3 as a full-blown Mackie controller with Ardour now, including timecode display, meters and scribble strips. Which is awesome, considering that just a few days ago I couldn't get the device to work at all in Linux. :)
agraef
commented
5 years ago Here's a little teaser, showing that it actually works (static text along with Ardour MCP feedback featuring timecode, meters and scribble strips):
Now if I could pipe some audio into the program and draw that on the screen, that would still be a lot cooler. :) Is Jack support on the TODO list? I see that there's already a Jack item in the meson/ninja configuration, but that doesn't seem to be used anywhere in ctlra right now. Jack MIDI and session support would also be nice.
harryhaaren
commented
5 years ago Hey Albert!
This looks awesome - most of the code changes look very reasonable and useful. I'm glad you got the device working :)
I think your usage of midizap is awesome, a very "hands on" solution to a problem. For me the longer term goal for Ctlra is to use the Mappa library for this type of comms. Mappa could/would/should include the "mapping" component of midizap, and the screen "templates" to fill in with data. Basically, we don't need JACK support in that model - because the application will integrate Mappa directly, and this enables much more "native" inclusion and integration of the app and the hw. Aka, not JACK specific, no MIDI connections, just native integration with a mappa_<app>_<device>.ini file, which can be generated from a UI...
Similarly for Jack Session - it will become part of the app, and Mappa is able to hotplug-load its .ini config files now - so it should all become transparent to the application and user in the long term.
I think your daemon code shows that Mappa is required - a generic solution to custom mappings. There are too many options, and for C coders like ourselves we can hack daemon.c to our own device and requirements, however it won't cater for the community... hence Mappa.
Unfortunately my time is short at the moment - and I've a backlog of Mappa fixes to do to finalize the API, and then finalize the Ardour/Mixxx prototypes... at which point I think we can demonstrate the real value of Mappa+Ctlra native integration into apps/etc.
I'm not against your midizap / daemon - its just long term I don't see it scaling well for all use-cases, so it shouldn't be merged into the generic Ctlra codebase IMO.
TL;DR: I'm happy to merge ni mk3 changes, and various bug-fixes (thanks, really appreciated!). I'm not sure about making the daemon.c in Ctlra repo specific to a device - although I gather that's not in the PR here either.
Hope that all makes sense, any questions / comments please let me know! Cheers, -Harry
agraef
commented
5 years ago Hi Harry,
thanks a bunch for your reply! I hope that you're doing well back in Limerick -- greetings to Seb!
First, the PR. Just to reassure you, yes, it only contains the various fixes to the Mk3 and MIDI backends that I thought were reasonable and useful for everyone using Ctlra, so I hope that you will merge these. If you still want me to squash it into a smaller number of commits, such as a single commit for each of the files, just let me know and I'll do it.
Second, the daemon. I'm not sure where to go with my beefed-up version of the daemon yet. It started out as a few basic hacks on the original and then it grew and grew... :) It's what I'm using now as a kind of proof-of-concept and a hacking ground, but I agree that it's probably not for everyone. I'll probably rename it to daemon2, daemon_mk3 or something and keep it in my fork for the time being, so that people can use it or just look at the source code if they want to. And once I figure out how to use Mappa to do the remaining translations so that it works without midizap, we might even pull it over into the main repo.
(NB: Talking about device specifities -- there's some stuff in the mapping_v1 daemon as well that will definitely not work if the device has anything but a 4x4 grid, so it's not entirely device-agnostic either. ;-) I'm actually trying to fix these things in my version of the daemon, but as I don't have any of the supported devices but the Mk3 to test, that's a little difficult. But I digress...)
Third, Mappa. I do know about Mappa and I fully agree that it's the way forward. I never meant to suggest midizap as a replacement for Mappa or anything like that -- it's just a stop-gap quick-and-dirty solution that I used to get things done until I see how Mappa can be used to do this kind of stuff.
I certainly could/should have used Mappa for my daemon version, and actually looked at it for that purpose. Unfortunately, there's not exactly a wealth of examples for it (at least I couldn't find them), and I just couldn't figure out how to quickly knock out a full Mackie emulation with it. Which is why I used midizap instead -- which is still under development as well, so I killed two birds with one stone there. ;-)
IMHO, there's a place for both Mappa and a tool like midizap, at least for the time being. Mappa is integrated with Ctlra, and it's great if you're a C programmer. Yes. I understand that once the basic mapping routines are implemented, it's just a matter of writing an ini file. But there's stuff like the horribly convoluted MCP and other protocols that we haven't even thought of yet, which will require special-case code to be written every once in a while.
midizap is for a completely different audience -- people who can't program and can't be bothered to learn it, or any kind of framework such as Ctlra/Mappa for that matter. Like you say, midizap is a pragmatic, quick and dirty solution for a problem that exists and really needs to be solved. Ctlra/Mappa will eventually serve that purpose, but until it's ready and supports pretty much any interesting device and flagship multimedia application out there, we have midizap to deal with the rest. Yin and Yang. Or you might say that you're constructing the spaceship, while I've built a horse cart. But a well-built horse cart can be a good piece of technology, too! :)
TL;DR: Can you merge this PR, please? Then I can think about what to do with my daemon version.
harryhaaren
commented
5 years ago Thanks for the PR - merged.
I agree that daemon is not "totally" neutral now - but hopefully in future it will be. Agree with the practical MidiZap vs space-ship Mappa analogy too - hopefully the spaceship will fly in the (near-ish) future :)
Thanks again, -H
agraef
commented
5 years ago Thanks a bunch!
agraef
commented
5 years ago Just for the record, I moved my extended daemon example to a separate branch now, renaming it to daemonx along the way -- which supposedly sounds somewhat mysterious. ;-) See https://github.com/agraef/openAV-Ctlra/tree/mapping_v1-daemonx/examples/daemonx.
harryhaaren
commented
1 year ago Hi @agraef and folks!
I've taken the branch, and copy/pasted the sample into master branch (~100 commits, with some conflicts...) so this side-steps that rebase. There's a new branch (https://github.com/openAVproductions/openAV-Ctlra/tree/add_daemonx_example) and a PR exists for the work here: https://github.com/openAVproductions/openAV-Ctlra/pull/109
Thanks again Albert! If no input, i'll merge into master branch in the next days.. -Harry
quimgil
commented
1 year ago Thank you @harryhaaren, this is very promising!
I have downloaded the code of this new branch. The short version is that the MK3 connects, events are registered to the console, my DAW can see the MK3 but MIDI learn or any other MIDI assugnment doesn't seem to work yet.
In detail:
Some errors when building, and I have no idea how relevant they are:
$ meson build
The Meson build system
Version: 0.63.2
Source dir: /home/icaria36/Music/openAV
Build dir: /home/icaria36/Music/openAV/build
Build type: native build
Project name: openav_ctlra
Project version: undefined
C compiler for the host machine: cc (gcc 12.2.0 "cc (Ubuntu 12.2.0-3ubuntu1) 12.2.0")
C linker for the host machine: cc ld.bfd 2.39
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Found CMake: /usr/bin/cmake (3.24.2)
Run-time dependency openav_avtka found: NO (tried pkgconfig and cmake)
Cloning into 'avtka'...
remote: Enumerating objects: 655, done.
remote: Counting objects: 100% (18/18), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 655 (delta 6), reused 10 (delta 3), pack-reused 637
Receiving objects: 100% (655/655), 138.87 KiB | 4.34 MiB/s, done.
Resolving deltas: 100% (399/399), done.
Executing subproject avtka
avtka| Project name: openav_avtka
avtka| Project version: undefined
avtka| C compiler for the host machine: cc (gcc 12.2.0 "cc (Ubuntu 12.2.0-3ubuntu1) 12.2.0")
avtka| C linker for the host machine: cc ld.bfd 2.39
avtka| C++ compiler for the host machine: c++ (gcc 12.2.0 "c++ (Ubuntu 12.2.0-3ubuntu1) 12.2.0")
avtka| C++ linker for the host machine: c++ ld.bfd 2.39
avtka| subprojects/avtka/meson.build:6: WARNING: Consider using the built-in option for language standard version instead of using "-std=c99".
avtka| subprojects/avtka/meson.build:7: WARNING: Consider using the built-in option for language standard version instead of using "-std=c++11".
avtka| Run-time dependency cairo found: YES 1.16.0
avtka| Run-time dependency x11 found: YES 1.8.1
avtka| Build targets in project: 1
avtka| Subproject avtka finished.
Has header "libtcc.h" : NO
Run-time dependency alsa found: YES 1.2.7.2
Run-time dependency jack found: YES 1.9.21
Run-time dependency libusb-1.0 found: YES 1.0.26
Dependency cairo found: YES 1.16.0 (cached)
Run-time dependency gl found: YES 1.2
Configuring config.h using configuration
Library m found: YES
Dependency jack found: YES 1.9.21 (cached)
Run-time dependency sndfile found: YES 1.0.31
Run-time dependency fluidsynth found: NO (tried pkgconfig and cmake)
Message: in examplesimple
Configuring loopa_mk3.c using configuration
Configuring config.h using configuration
Build targets in project: 4
openav_ctlra undefined
Subprojects
avtka: YES 2 warnings
Found ninja-1.11.0 at /usr/bin/ninjaSome warning when running ninja:
ninja
[26/30] Compiling C object ctlra/libctlra.so.p/usb.c.o
../ctlra/usb.c: In function ‘ctlra_dev_impl_usb_interrupt_read’:
../ctlra/usb.c:588:17: warning: ‘free’ called on pointer ‘async’ with nonzero offset 24 [-Wfree-nonheap-object]
588 | free(usb_data);
| ^~~~~~~~~~~~~~
../ctlra/usb.c:550:37: note: returned from ‘malloc’
550 | struct usb_async_t *async = malloc(size + sizeof(struct usb_async_t));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../ctlra/usb.c: In function ‘ctlra_dev_impl_usb_interrupt_write’:
../ctlra/usb.c:693:17: warning: ‘free’ called on pointer ‘async’ with nonzero offset 24 [-Wfree-nonheap-object]
693 | free(usb_data);
| ^~~~~~~~~~~~~~
../ctlra/usb.c:662:37: note: returned from ‘malloc’
662 | struct usb_async_t *async = malloc(size + sizeof(struct usb_async_t));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[30/30] Linking target examples/ctlra_simple
`
All good when running the example:
`sudo ./examples/ctlra_simple
[sudo] password for icaria36:
simple: accepting Native Instruments Maschine Mk3
connected devices 1
[ ->] encoder Enc. 1 Turn (1) type = smooth
[ ->] encoder Enc. 2 Turn (2) type = smooth
[ ->] encoder Enc. 3 Turn (3) type = smooth
[ ->] encoder Enc. 5 Turn (5) type = smooth
[ ->] encoder Enc. 6 Turn (6) type = smooth
[ ->] encoder Enc. 8 Turn (8) type = smooth
[ X ] grid 8
[ ] grid 8
[ X ] grid 9
[ ] grid 9
[ X ] grid 9
[ ] grid 9And etc, all buttons and knobs seem to be registering events properly.
Both displays are on, but black. No lights in the device, no lights registering interactions e.g. pressing pads. I have no idea whether these are supposed to work, I'm just reporting. :)
Enter Bitwig, last version. Adding the MK3 as a controller works, as in the MIDI 1 in & out are detected. But from this point, nothing else seems to work. Interactions are not registered as far as I can see, and MIDI learn doesn't work.
For what is worth, I tested also with Native Instrument's Controller Editor, which happens to launch using Wine. The MK3 is not selectable by this application, but this could be a problem with Wine compatibility or who knows what inside this proprietary app. I just thought I would try. :)
harryhaaren
commented
1 year ago sudo ./examples/ctlra_simple ah... you're running the "simple" app that only prints events, not turn them into MIDI ones!
make sure to enable the compilation of the daemonx example app (meson configure -Dexamples=daemonx from the build dir), and then run ninja again (to compile it).
Then try sudo ./examples/ctrla_daemonx ... and that should/might work? :)
harryhaaren
commented
1 year ago (Side note; yes those USB warnings should be fixed - they're kinda bad, so i'll try get around to them soon)
quimgil
commented
1 year ago Ooops, I'm sorry! I'm just someone trying to get this beautiful controller to work on Linux and I have no idea about programming and surroundings. :)
Ok, there is some progress but still no MIDI messages:
sudo ./examples/ctrla_daemonxAll good.
$ ninja
[0/1] Regenerating build files.
The Meson build system
Version: 0.63.2
Source dir: /home/icaria36/Music/openAV
Build dir: /home/icaria36/Music/openAV/build
Build type: native build
Project name: openav_ctlra
Project version: undefined
C compiler for the host machine: cc (gcc 12.2.0 "cc (Ubuntu 12.2.0-3ubuntu1) 12.2.0")
C linker for the host machine: cc ld.bfd 2.39
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Found CMake: /usr/bin/cmake (3.24.2)
Run-time dependency openav_avtka found: NO (tried pkgconfig and cmake)
Executing subproject avtka
avtka| Project name: openav_avtka
avtka| Project version: undefined
avtka| C compiler for the host machine: cc (gcc 12.2.0 "cc (Ubuntu 12.2.0-3ubuntu1) 12.2.0")
avtka| C linker for the host machine: cc ld.bfd 2.39
avtka| C++ compiler for the host machine: c++ (gcc 12.2.0 "c++ (Ubuntu 12.2.0-3ubuntu1) 12.2.0")
avtka| C++ linker for the host machine: c++ ld.bfd 2.39
avtka| ../subprojects/avtka/meson.build:6: WARNING: Consider using the built-in option for language standard version instead of using "-std=c99".
avtka| ../subprojects/avtka/meson.build:7: WARNING: Consider using the built-in option for language standard version instead of using "-std=c++11".
avtka| Dependency cairo found: YES 1.16.0 (cached)
avtka| Dependency x11 found: YES 1.8.1 (cached)
avtka| Build targets in project: 1
avtka| Subproject avtka finished.
Has header "libtcc.h" : NO (cached)
Dependency alsa found: YES 1.2.7.2 (cached)
Dependency jack found: YES 1.9.21 (cached)
Dependency libusb-1.0 found: YES 1.0.26 (cached)
Dependency cairo found: YES 1.16.0 (cached)
Dependency gl found: YES 1.2 (cached)
Configuring config.h using configuration
Library m found: YES
Dependency jack found: YES 1.9.21 (cached)
Dependency sndfile found: YES 1.0.31 (cached)
Run-time dependency fluidsynth found: NO (tried pkgconfig and cmake)
Message: in exampledaemonx
Configuring loopa_mk3.c using configuration
Configuring config.h using configuration
Build targets in project: 4
openav_ctlra undefined
Subprojects
avtka : YES 2 warnings
User defined options
backend : ninja
examples: daemonx
Found ninja-1.11.0 at /usr/bin/ninja
Cleaning... 2 files.
[1/2] Compiling C object examples/ctlra_daemonx.p/daemonx_daemonx.c.o
In file included from /usr/include/string.h:535,
from ../examples/daemonx/daemonx.c:6:
In function ‘strncpy’,
inlined from ‘daemon_screen_redraw_func’ at ../examples/daemonx/daemonx.c:733:5:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:95:10: warning: ‘__builtin_strncpy’ destination unchanged after copying no bytes [-Wstringop-truncation]
95 | return __builtin___strncpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
96 | __glibc_objsize (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~
../examples/daemonx/daemonx.c: In function ‘accept_dev_func’:
../examples/daemonx/daemonx.c:957:9: warning: ‘__builtin_strncpy’ output may be truncated copying 31 bytes from a string of length 31 [-Wstringop-truncation]
957 | strncpy(daemon->screen_text[1][0], info->vendor, SCREEN_COLS);
| ^
../examples/daemonx/daemonx.c:958:9: warning: ‘__builtin_strncpy’ output may be truncated copying 31 bytes from a string of length 31 [-Wstringop-truncation]
958 | strncpy(daemon->screen_text[1][1], info->device, SCREEN_COLS);
| ^
[2/2] Linking target examples/ctlra_daemonxMmm.... ok, let's see.
sudo ./examples/ctlra_daemonx
daemon: accepting Native Instruments Maschine Mk3 (17cc:1600)
daemon: connected devices: 1The displays show static text, no parameters:
Ctlra Native Instruments openavproductions.com Maschine Mk3
Maschine's MIDI 1 in & out are detected by Bitwig. However, still no MIDI learn and no MIDI events that I can see.
The console has no output, but I don't know whether any is expected.
I try --help to see whether there is a --verbose parameter or something. There isn't but I see this -f to enable feedback. Running the application now with -f, lights appear when touching pads and buttons.
In any case, these lights don't seem to help producing MIDI notes.
Happy to keep testing if you have a bit of patience with me! :)
PS: fwiw I'm running Ubuntu 22.10 kinetic with low-latency and Pipewire (now default).
harryhaaren
commented
1 year ago OK: a few seperate things 1) I need to incorperate some other changes from Alberts branch (changing the mapping ID numbers) to match the lights to the buttons. That's my bad - I must have missed some changes (because I tested Alberts code and that was working perfectly!)
2) Bitwig I/O: I'm not sure here, but can you attach a "midi monitor" to see are any messages going out? (There's some other changes to be made in the code to improve MIDI message I/O, again, those are part of the set which Albert changed and I left out earlier...)
The fact the screens light up & show the Ctlra/OpenAV etc text is a good thing, making progress! I'll need to integrate those code changes and test here locally myself to be sure before pushing a fix, please give me a few days...
harryhaaren
commented
1 year ago OK, added a bunch of Albert's commits to the branch, testing working fine here now...! (details, the last 8 commits here https://github.com/openAVproductions/openAV-Ctlra/compare/master...add_daemonx_example) Thanks again Albert for fixing issues in the Ctlra library MIDI I/O code, and in the Mk3 backend!
Testing testing... touchstrip issue still exists, pushing commit to fix now (https://github.com/openAVproductions/openAV-Ctlra/commit/f2313904c7f86a629f3d37863a691c950ff9b66c).
Tested using "a2jmidid" to convert ALSA MIDI into JACK MIDI, and then using jack_midi_dump to check what MIDI I/O is happening (on the consolve of the midi_dump program). MIDI Messages appearing as expected, and lights on the device lighting up as expected too (with daemonx -f flag enabled).
That's all for today... but I think that's everything! Please test @quimgil, and report back :)
quimgil
commented
1 year ago Progress!
Something that I have noted in Pianoteq is that there are two MIDI inputs detected:
Strange, but solvable in Pianoteq by ignoring the first and selecting the second.
For some reason, Bitwig only sees "Maschine MK3 MIDI 1", and I can't find a way to add "Ctlra Maschine Mk3_output".
Hi Harry,
as you know I've been working on using Ctlra to make the Maschine Mk3 work for me on Linux. Works great, Ctlra is really nice!
However, along the way I found and fixed some bugs in the Mk3 backend (rev. 829eec81d81337910784ad7dbc13dabd09e6df7e) and I also had to enlarge the MIDI buffer sizes on the input side (rev. ea0a486fc0ff3aa3d3e2c1a0d39a82a251dd7c38), so that I can receive sysex messages which I'm using to control the daemon from outside, and also for Mackie feedback emulation.
I hope that these are acceptable as they are, if not please let me know how to improve them. Once this has been merged into mapping_v1, I can follow up with my extensive rework of the daemon example.
Thanks,
Albert