Midi Clock in -- questions

hey guys, so been looking over the clocking capabilities of the Percussa SSP.

So I see @thetechnobear module CLKD and there is an option there “Midi” … so I have my midi device pluged into USB #2. which is the Oxi One. And I have Midi triggerd working using the MIDI app… but thats all I can seem to get working on the Midi → CV route… couldnt get midi triggers working with the Midi to trigger or midi input modules except for MIDI module so I must be doing something wrong… I am going to the Midi pager with left+shift and right+shift, selecting my midi channel and selecting my midi in device which it is recognized… I tried learn… but learn doesnt seem to be picked up… obviously this is PEBCAK error

Wait I think I understand it.

Highlight:

  1. MIDI Module → {Right Side} Clock: CLKD:Midi Clk
  2. CLKD Module → {Left Side} CLKD: Midi Clk ||| {Right Side} Clk A: Out:In8
  3. OUT Module → {Left Side} OUT: In8
1 Like

the MIDI module is a standard module so i don’t think it has MIDI learn

you can trig exactly 1 note from MIDI (it is in OMNI mode) - imagine it as you playing an (very) old monophonic synth

although it will listen on all 16ch (hence OMNI), this is configurable
also, if will let you configure 8 MIDI cc values to convert to CV

to bring out a trig from the SSP (believe this is what you’re up too if i read above correct), you should be able to do ‘direclty’ from MIDI module, no?
-be that derived from a MIDI clock signal or a MIDI note conversion to trig

Thanks.

This is great.

So when I get into a system I begin developing for and naturally during that experience I experience it’s sometimes many workflows just having to use it like any user of it would…. Whatever it may be… and during this process I find these occurances that aren’t initially intuitive for me, where I get frustrated, have to reach for the manual, ask someone, resort to google, pray to the gods, just start putting X to Y and hoping a change occurs, insert cunning phrase here….whatever… It’s these times like those that equally I find are the most rewarding.

Many years ago when I first got into programming a mentor told me something I have remembered for the rest of my life now… treat every inconvenience as an avenue to create gold.

Because it’s these I find avenues for improvement… it’s these that I find the most exciting.

For instance. In the OUT (put) module. Learning what “ins” corresponds to the physical1-8 outputs… even though you see 1 through 24 and intuitively might count the physical jacks 1 through 16 being reserved for the inputs perhaps and 17 through 24 being the outputs… which obviously is not the case.

Unfortunate even a standard manual would instantly answer. But regardless, all those things I note because of it was a problem initially for me…! Imagine it was for other people as well.

Testers are gold. Pure gold. It’s so common as engineees and developers what we might think as incredible evident UI and workflows for us are absolutely the opposite for the target user.

And a big game occurs of iterating, adding, a-ha simplicity, ok let’s add more… boom now it got complicated, ok dial back, change this, competely re-world that… three steps forward… two steps back.

Rinse and repeat.

1 Like

Ibe been a DevOps engineer now since 2014. A term coined in first in 2010 when cloud was just emerging and us younger system admins and engineers were replacing the guards of yesteryear that I learned to not get too attached to an idea, be able to pivot quickly. Stand on the shoulders of giants, not reinvent any unnecessary wheels, all the saying, Etc etc.

Ok. I’ll get off my soap box now.

yeah, docu could be way better - luckily we have the wiki SSP
agree that the logic behind naming ports is totally not logic, not from a musicians point of view, not from a producers or tech - it is a sole view

i do like testing SW (done lots in the past), but of course only from my point of view (without test script)

for avenues of (pro) creation, i’d like to move smooth, slick & no bums/bummers - if need to revert to manual or something is not happening as planned (by me), then i get de-motivated/de-inspired - difficult to get back on track // i hate “workarounds” or detours

i’ve been into IT since 1980, so lots has changed/is changing since - we even hadn’t HD on those first computers (PCs)

1 Like

ok, so the “fundamental” issue with the SSP synthor implementation, and its MIDI module is it only target the first midi device that connects, on the first port.

this is a problem for some midi devices these days which have multiple ports, or using things like midi hubs. so if you have lots of midi devices (as I do), this is a big issue.

unfortunately, as you know, the SSP SDK api, does not provide access to midi at all, so you cannot really do anything in your own module.

so this is the “reason” for my midi page, so connect directly to midi devices (via the juce api)

note: be careful if you do this, I had quite a few issues with juce crashing, when switching presets, or clobbering the synthor… not quite sure what the fixes were, but if you have issue, you can check my code. (it may have been the. internal midi thru?)

as for the LS/RS access, yeah its not the most intuitive…
but unfortunately, by the time, I got to wanting to do midi learn, I had developed quite a few modules, and has a very consistent UI/UX, that potentially used every button, and many button gestures already (PMIX, uses almost every combo ;)) ( * )

so, I decided, I didn’t want to interrupt the natural UX of the modules for a kind of ‘system’ function, so LS+RS it became… a weird combo, not already in use.

for you, really depends, on how complex your UIs get, and how strictly you decide on what buttons will do, and consistency across modules… the real ‘fun’ starts when you have pages of parameters, and want fast access to them all… but you’ll no doubt find that sooner or later.

I don’t really know what you plans are ( ** ), but Id probably avoid (your own) midi initially if you can, do it all via CV, and rely on whats there - users will always want to drive via CV (to integrate with other modules) , so midi is a bit of a ‘bonus’.
(also midi clock implementation is ‘fun’, as midi clock is so unreliable ;))
pick your battles :wink:


( * ) dont even get me started on the XMX, as it has even less buttons, I had to find a whole new class of gestures … , so I did a complete refactor again on button gestures, to not only allow combos, but also things like long / short press differentiation, and messing with action on press vs on release…

( ** ) sorry, I know you’re providing lots of detailed posts, so Im sure I could figure out what you are up to, and even participate .
however, unfortunately its bad timing, Im in the middle of a big / complex hardware project, so really dont have the time / capacity to focus elsewhere.
So, I’m kind of limiting myself to the “headlines”, and giving you info from what Ive done / encountered, which may or may not be relevant, so you can take or leave. but better than nothing (hopefully)

lol, I just realised Id forgotten my own module! :man_facepalming:

yes, CLKD is not using the midi page… its using clk from MIDI via a cv in.
I suspect, probably I did this pre midi page, and didn’t think about updating it?!

probably what I should do is also allow the clock to be taken in CLKD from the midi page as well… so I could get the benefits as per previous post.
( probably add clock to MTIN as well, might be nice)

Hey man I got a question on bus count… so If I have under 24 ins… like pitch, trigger, etc etc per pad… but if I have more like if I want to have cv to start and end and patch a clock over it crashes… does bus count really matter like this?

you dont need to cross-post, I’ll answer on any topic :laughing: