logue-cli load issue on Linux #37
Comments
|
Did you specify a slot with the "-s" option as shown in the example in README.md? Like this: $ ./logue-cli load -u my_oscillator.mnlgxdunit -s 2 The 2 as slot number in above is just a example. to determine the slot number, you should first check the list using the "-m" option. It is better to be careful whether the number starts from 0 or 1. |
|
Hi, |
|
My NTS-1 has the following size limits, what are the numbers on your Minilogue XD? Is its size enough compared to mnlgxdunit files? I would like to try it out, so if it's an open oscillator I'd be glad that you share it. |
|
Hi, The oscillators I am trying are from https://github.com/peterall/eurorack-prologue ; pre-compiled versions are also available on the GitHub "releases" page for that repo. |
|
Hi, thank you for sharing the nice package. The issue has been reproduced on my Ubuntu 18.04 too. The "dmesg" says following. Do you have a way to configure the buffer size? Unfortunately, I am not good at Linux sound architecture and have no knowledge. |
|
It's good to see that the behavior is at least consistent and reproducible. I was thinking something along the buffer size lines, as well. I did a bit of searching before I opened the ticket and came to the conclusion that this looked like something that needs to change in the application. It was difficult to find resources online, but I believe I saw in a couple of places that the default buffer size was a system page (4096 bytes on x86). The demo "waves" oscillator seems to be under this threshold, at least in its compiled form on disk, which might explain how it gets by without overrunning the buffer. The closest thing I've found is https://alsa-devel.alsa-project.narkive.com/6w35hffF/sysex-overflow-when-using-the-midi-sequencer-event-interface , which sounds like a similar symptom, and indicates that the "correct" fix is that this should be fixed in the software. There's also https://marc.info/?l=alsa-devel&m=154580126006810&w=2 describing a bit more about an easy way to fill the buffer. That said, I tried to take a crack at a workaround by changing this via |
|
I have a similar problem to the above with my NTS-1 on Ubuntu: |
|
I have figured out a way to load a user oscillator on Ubuntu, though this should work Use the "-d" switch with your load command. the last part on the screen (which is on one line BTW) should be the complete MIDI Sysex command for loading the oscillator So my flow works like this:
Then you find the ALSA rawmidi hardware port like this: amidi -l The second minilogue xd port listed is the one that worked for me I send the oscillator to the minilogue-xd like this:
I've loaded several of the free eurorack oscillators this way. The real issue is that the program uses an ALSA sequencer port, and not an ALSA rawmidi port to send the sysex messages, the sequencer port limits the length of any message, while the ALSA rawmidi "port" has no such limitations. I've attached my Perl script released under the MIT open source license, so it's just an attribution, and has a disclaimer in case it doesn't work for you... |
|
@aminixduser You are brilliant! This works well for me. I was having trouble loading an effect but this worked for me. I had trouble with your perl script, but I used your approach with just sed. Create the load log:$ logue-cli load -v -i 1 -o 1 -s 0 -u tempo_delay.ntkdigunit -d > load.log(my NTS-1 is on i/o ports 1 and 1) Extract just the sysex$ tail -n1 load.log| sed 's/,//g' | sed 's/}//g' | sed 's/{//g' | sed 's/>//g' | sed 's/^ *//g' > load.sysexSend over amidi$ amidi -l
Dir Device Name
IO hw:2,0,0 NTS-1 digital kit MIDI 1$ amidi -p hw:2,0,0 -S `cat load.sysex`Works beautifully. What a nice and simple solution, such a cool machine! |
|
@schollz That's a great way, I should have thought of the tail -n1 to get the last line as many times as I've used it. I rarely use sed, but this is a great little batch of regex one liners. |
|
The work-around with the perl script also works for me! Hope Korg will update the logue-cli to deal with this though. |
|
@schollz and @aminixduser thx for the cool workaround! I tried both your methods (on ubuntu 16.04) but failed to send the extracted sysex file to my minilogue with Update: ok, just after positing here I was going over the settings in the minilogue again and changed my midi port from 3 back to 1. This somehow did the trick, in case someone else is having issues. |
|
I am not very good with bash script but something like this should be a starting point: #!/bin/sh
echo "Load with params: $@";
temp_file=$(mktemp)
echo "Tmp file $temp_file"
in_port=$(./logue-cli probe -l | grep NTS-1 | grep in | awk '{print $2}' | sed 's/.$//')
out_port=$(./logue-cli probe -l | grep NTS-1 | grep out | awk '{print $2}' | sed 's/.$//')
amidi_port=$(amidi -l | grep NTS-1 | awk '{print $2}')
./logue-cli load -d -i $in_port -o $out_port -u $@ > $temp_file
tail -n1 $temp_file| sed 's/,//g' | sed 's/}//g' | sed 's/{//g' | sed 's/>//g' | sed 's/^ *//g' > "$temp_file.sysex"
amidi -p $amidi_port -S `cat $temp_file.sysex` |
|
Sad to say this workaround doesn't work for me, either with the Perl script or the tail ... sed thing. amidi takes a fraction of a second to execute with no errors -- but the module has not been loaded. |
|
Got it! On my NTS-1 I reset the midi channel to 0, and then it worked! |
|
I wrote a Python 3 script that takes the excellent work that @aminixduser shared and expands upon it a bit. Here it is: Basically, this To use the program, gunzip it, chmod it to be executable, and either put it somewhere in your $PATH or reference it with ./, just like any other script on Linux. It accepts Below is an example session in action. Most of the commands are just illustrating how to find the device and such using
Ideally, the |
|
I made the script a bit more succinct. removed extraneous use of grep & sed and removed the use of temporary files. #!/usr/bin/env sh
[ -z "$@" ] && echo "no params" && exit 1
# Read ports.
read -r midi_in midi_out amidi <<EOF
$(logue-cli probe -l | awk '/NTS-1/ {ORS=" "; gsub(/[[:punct:]]/, ""); print $2}')$(amidi -l | awk '/NTS-1/ {print $2}')
EOF
echo "in: $midi_in out: $midi_out hw: $amidi"
# Try loading unit. If it times out, parse sysex messages and send them using amidi instead.
out="$(logue-cli load -d -i $midi_in -o $midi_out -u $@ 2> /dev/null)"
[ $? -ne 0 ] && (
echo "logue-cli failed! trying amidi."; echo "$out" | awk 'END {gsub(/[[:punct:]]/, ""); print}' | xargs amidi -p $amidi -S
) && echo "done!" |
|
Great workarounds guys! But please @etienne-korg could you have a look into this? If you don't have the time to fix it, just open the sources and we would be pleased to fix it for you :) |
|
It's possible to resize the MIDI output buffer with this command, which solves this issue for me. I've discovered this recently but looks like it's an old feature of the As others have said, using the sequencer interface in Linux for SysEx or the like is totally inadvisable but cross-platform libraries such as PortMidi or RtMidi do this. It could be fixed permanently if we configure the parameter so the OS uses it when loading the module but this is probably undesirable as the smaller the buffer the smaller the latency. After all, that's why we have 2 different MIDI API's. |
|
Here's a solution based on the workaround by @dagargo but it also restores the original buffer size #!/usr/bin/env sh
# Save buffer size
buffer_size=$(cat /sys/module/snd_seq_midi/parameters/output_buffer_size)
# Set temporary buffer size
echo "65536" > /sys/module/snd_seq_midi/parameters/output_buffer_size
# Send arguments to logue-cli
logue-cli "$@"
# Restore buffer size
echo $buffer_size > /sys/module/snd_seq_midi/parameters/output_buffer_size |
Hi,
I am trying to upload third-party oscillators using logue-cli to a Minilogue XD on Linux. Unfortunately, I seem to get different symptoms consistently for different respective oscillators. One symptom is a timeout, with the message
ALSA: seq_midi: MIDI output buffer overrunshowing up in dmesg at the time of the issue. The other symptom is an actual midi error from the application, without the same message in dmesg. I am speculating that these could be similar. I am wondering what steps I could try, to help get to the bottom of the issue. I was able to upload a self-compiled version of the waves sample oscillator, which makes me wonder if it's something specific with size or something else about the oscillators that causes the MIDI error. I tried both compiling the third-party oscillators myself and using the precompiled version, without luck. Please let me know if more verbose output would help; I can see a wall of hex when I run the tool in debug mode, before it times out.OS version: Linux Mint 19.1 (based on Ubuntu 18.04)
Minilogue XD firmware version: 2.10
Kernel version: 4.15.0-88
alsa-base package version: 1.0.25
The text was updated successfully, but these errors were encountered: