I am trying to understand the aftertouch signals that my midi controller (Alesis Vortex 2) sends. When I look at the midi log in the web ui, it just says CH#00 AFTERTOUCH. I can’t tell whether this is channel aftertouch (Dn) or key aftertouch (An) and there should be a number for the pressure (or two numbers for key and pressure for key aftertouch). Is this a bug in the midi logging? Is there another way of seeing the midi signals received (like ssh’ing into the zynthian) ?
Probably the best thing to do is file a git hub issue . . .
SSH, Putty is is the zynth preferred way of getting a terminal. Sadly on windows there is a bit of a game with local name resolution so you might find you get more joy using the IP address rather than the zynthian.local name. It can be sorted but Apple becomes involved 
)
As far a MIDI monitoring goes, there are (of course) several techniques. These ain’t running on a zynth but kind of demonstrate the ideas . . .
Your first friend is aseqdump . . .
Cntrl-C to get out . . .
one of a raft of alsa tools that do various pure operations on a linux audio system, but unlike windows this sort of doesn’t have ‘nice’ defaults you have to tell it what to look at, and once you get your head round it it’s the best way but it’s irritating in the early days . . .
if we run aseqdump &
(Notice the & on the end: This runs it but returns a prompt to your terminal (well you might have to press return… ) , which means we can start to think about joining a MIDI in port . . .
But of course you should always have a look around to see what the machine believe’s it can see . . .
aconnect -l
and we can see the aseqdump connection . . .
But my laptop has no MIDI Port !!! The Midi Through Port-0 is a software construct and best ignored.
So I’ll fire one up that listens to any midi messages coming over the Ethernet connection.
using QMidiNet,
IT’s a linux thing but it can talk to Windows via a known standard . . .
So we now have two MIDI devices . . . which we can ‘patch’ together with aconnect . . .
and if we turn on MIDI networking ( webconf or GUI) on a remote zynth, (zynthian-nord.local which has a Behringer Motor 61 with aftertouch connected)
, we can see the notes played on the zynth appear in the output of the connection we have just created . . .
And that’s one way Which is why the zynth MIDI display is such a blessing so . . . . .
Hopefully this demonstrates some of the complexities that the zynth is solving for us, and we haven’t even mention Jack yet
The MIDI logger code back end
with the front end being rendered by the tornado framework in a template html file
Probably the best thing to do is file a git hub issue . . . Don’t worry you don’t need to indulge in the code at all, that’s just for those that want to see how open, open-source actually is :-). Just describe the issue/problem and the machinery will grind away …
Course you could demand an explanation of this on the zynth as well . . . We run a remarkably fluid gratitude expression model round here and I’m sure the joys of jack need examining . . . 
@wyleu Thank you so much!! That is perfect! I am a software engineer, and am pretty familiar with the the unix command line. Thus far, my osx machine seems to resolve zynthian.local pretty reliably, and I have connected with ssh several times to pole around. I will checkout aseqdump and aconnect.
So far, I’ve only seen one synth engine that supports aftertouch, dexed, and it will need a bunch of tweaking to be musical. I was hoping to be able to use aftertouch for vibrato, either a manual vibrato where key pressure causes a slight pitch change (for horns lower, for guitar higher), or one where the key pressure increases the speed and/or pitch variation of the vibrato.
Here’s a nice demo where Jeff Gastineau from Alesis seems to be using a manual vibrato (also with maybe a chirp effect). https://www.youtube.com/watch?v=oakdcIKtE8g
I saw another post about maybe mapping aftertouch messages to a different midi message.
yes osx is using bonjour to do the avahi (to my mind) name resolution, so it’s only an issue if you are using a Windows host, which I tend to assume most people are …
Poking around on a zynth will start to reveal that ther ALSA elements I have described above are hidden behind another layer of abstraction; JACK. JACK is what does the zynthian audio magic and it’s best to think of the ALSA ports we have described above linked into a low latency different world environment that can combine multiple audio streams seamlessly, and it handles the MIDI elements as well ALSA handles the physical connections JACK does all the routing . . . .
Now normally you’d jump into qjackctl at this point …
but we seem to have an outstanding issue on that one running on the zynth in zynthian os . . . .
1 Like
Also, I’ll file a github issue. As a developer I know the value of finding bugs, especially with clear steps to repro. You can’t fix what you don’t know about. Seems like a simple fix. I would even take a stab at fixing myself, especially with a little guidance to the location of where to look in the code.
Yes that’s absolutely the right thing to do. The relevant code seems to be . … .
It simply hasn’t been implemented yet . . . .
The correct response is to fork the repo . . .
mido is doing the heavy lifting in the file /home/wyleu/PycharmProjects/zynthian/zynthian-webconf/lib/midi_log_handler.py . . .
hack the code, and once you believe you have a fix submit a pull request … 
OBviously this is a lot of setting up initially, I’m just following a route for this that I’ve been meaning to do for a long while …
2 Likes
@wyleu Okay, tested and PR submitted. https://github.com/zynthian/zynthian-webconf/pull/99/commits/5beb2e4e9a1a14c9204c657430b66429a58dedf6
3 Likes
Well, actually didn’t test the polytouch part since didn’t have a device to generate those.
Thanks that’s a magnificent effort !!
1 Like
PR merged! 
3 Likes
2 Likes