Percussa Home / Shop / Contact /

TheTechnobear's SSP/XMX development

SSP SDK
#423

ok, so Ive release a new beta for SSP , which can also be considered a ‘release candidate’.
if no issues are found over the weekend, then I will release this after.

note: the following only relates to the SSP , XMX is unaffected.
Ive not had any reports of issues with XMX plugins / trax, so the xmx version will move from beta to release at same time as SSP version.

this beta/rc resolves the known issue with Trax, and takes a new approach to the underlying ‘issue’ :slight_smile:

so, I had a discussion with Bert, as I wasn’t very happy with the ‘hacked’ build we used for Beta 3.

it didn’t feel like a sustainable approach, and also its not how Ive been using the plugins/trax during development - so Im trying something different…

with agreement from Bert, I’m including an unofficial version of Synthor, that is my build.
this uses newer build tools, and so is compatible with my plugins ‘unaltered’, so Im not longer hacking anything.
the advantage of this approach is two fold.
a) this build of synthor is the one I used during development, so Im releasing on something Ive been using for quite a while.
b) moving forward, I can continue to use latest versions of build tools and things like juce.

what does ‘unofficial’ synthor mean?

  • unsupported by Percussa
    any bugs / issues you find must be tested against the official release 13072022 to be reported.
    frankly, whilst Ive not had any issues with this build , I cannot 100% guarantee the build doesn’t have any side effects.
    so rename/keep backup of the official version, just in case you need to test.

  • functional identical
    it’s “just” a rebuild of the same source code as released, don’t expect any changes in functionality.
    its sole purpose is to use these new plugins.

anyway, from my testing, this solution fixes the issues we were facing, which were becoming time consuming activity to track down and try to ‘workaround’.

so Im pretty happy :slight_smile:

as above, if there are no further issues spotted over the weekend, then this will become my release.
if you install/test now, its unlikely this will change again, as the release will be this zip file as is.

nothing more to say other, than give it a go, and enjoy

Mark

2 Likes
#424

Thanks Mark for the update and deving on this project. Ill give it a go. Just to make sure the ‘unofficial’ SYNTHOR you’ve provided just requires replacing the existing one inside the SSP built SD card as far as that process goes?

Cheers again

#425

Yeah, just replace it.
you can back it up somewhere or rename it , in case you need to test something in the future with it.

2 Likes
#426

copy that thank you,

I haven’t much time but in the little time i did test some of the features most everything was solid. I did have issues with Trax still crashing the system if i removed Trax plugin and i had a couple instances of crashing within Dual when swapping out modules but i could not pinpoint what caused the crash in Dual however in Trax the removal of the plugin would cause repeatable crashes for me on my ssp.

#427

I just downloaded/reinstall from the wiki the last beta, and I cannot reproduce any issue.
can you reinstall, ‘just in case’ - specifically remove the plugin directory, and delete SYNTHOR beforehand

other than that, Id need a minimum step reproducible case.
a patch with just IN, OUT and TRAX
then in Trax, put CLDS on track 1, and connect it.
save it.
then delete trax.

Ive done this now countless times, and never crashes.

its important I know if its just related to this simple case…
if this works, then we can add more complications e.g. more tracks.

but if this basic test doesn’t work, Im not sure where to go next

Im a little concerned by this…

when you say ‘assume’ , what do you mean?
if you don’t know for sure, then this may have to be the first step.
(or at least until, someone else reports they have the same with this as a known image)
the thing here that image is not just synthor but the entire linux image, so if you have something else, there could be a library difference !?

that said, I think we should establish if a basic test is working the same first.
before undertaking anything more time consuming.

#428

Sorry for any inconvenience or confusion Mark,

So starting at the top

i have a blank SD card i just installed a fresh image on with the iso image that percussa has posted in the forums which is the most recent image i can find dated from 2022 found here Percussa SD card Image

I then deleted and replaced both the SYNTHOR file and Plugins folder with the ones from the wiki recent BETA I found here

The crash i am able to reproduce with this still I did on accident i added Trax to a spot on the plugins sheet and just immediately went to delete it (so i never opened trax to add or change any settings) and that causes the crash for me.

Once i open trax though all works as intended and i can add/delete with out any crashes its just the first time of adding trax (not opening it) and then removing it. This is a small and most likely very rare case that most anyone might run into this issue.

I also wanted to ask if maybe there’s something im not doing right within trax or of this is a bug on my install perhaps but to get the vue meters within trax to show signal output. Ive watched your tutorial on trax with xmx and ssp and have no issues with all the functionality Ive tested so far outside the 4 VU meters never show signal even though there is output coming out of trax ( as a note the volume and mute all function as intended.) i maybe missing something simple though.

The test for this i did is just a simple out and trax on the ssp and within trax i just have PLTS running to the output of ssp. I also tried adding IN and OUT as well as Trax with plts running inside trax with an external envelope generator modulating into the V/Oct of plts within trax as well and that all works (i can also can delete trax without issues) its just no VU display.

Thank you again

1 Like
#429

apologies, not implying its your fault or its an inconvenience.
I’m also really grateful for your help in testing this out, whilst its frustrating for me (as I appear to be going around in circles fixing this), having it crash for someone else is very useful feedback.

as for now…
well, I couldn’t reproduce your issue, but then I cleared my 000 patch, and now I can.
no idea why…

though, shows the power of having multiple users testing, we all having things setup slightly different!

this is leading to me believe its some kind of “random” memory corruption, which explains why the issue seems to move around, and also why you and I see different behaviour.

this is a tough one, as Im not seeing it on my Mac, when testing the trax plugin on its own.
but then again, Synthor is doing its own plugin loading, has its own version of Juce, and its own custom memory allocator - any it could be (likely?) that is one of these things thats somehow not playing nicely.
the issue is, theres no current leads as to where the underlying cause is…

the one piece of ‘good news’ is - you have it crash before loading anything…
this means its not the loading of modules within Trax.

can you do a few tests for me…

preparation - lets get to a ‘known state’
clear the default 000 patch. and save it, the reboot
now when the SSP powers on it , it loads a blank patch.
(you can restore factory patches later if you want them, or use wriN to save the 000 patch)

follow exactly, don’t bring UI of trax up, unless stated :wink:

a) create TRAX , and delete it
Im assuming it will crash

b) create two TRAX ,
delete one - doesn’t crash
delete 2nd - it does

c) create one trax, bring up UI
now delete - does not crash

d) create two trax, bring up UI on
delete both, does not crash?
create trax, no ui
delete does not crash

hopefully, you’ll get the same, which at least shows we are consistent

from the above, its feels like its a variation of the original issue, where deleting plugins without bringing the UI up, causes a crash… but Ive no idea why its now a specific issue just for Trax.
but at least its something to go on…

the UP/DOWN red buttons on the SSP are equivalent to the red buttons next to the screen on the XMX.
so holding up will always bring you to the main mixer screen. (with vu meters)
similarly holding down, always take you to the performance screen.

the main reason for this is when you are in the module view (e.g. CLDS), I need up/down up/down are used to go between parameter pages.
basically, I ran out of buttons/gestures to use on the xmx, as every button is (potentially) used within a module.

I tried various gestures, including two button combos, but I found most either fiddly or difficult to remember.

so I went for one extra gesture HOLD = 2nd function.
also I liked the idea that hold up/down would take you to two important screens mixer/performance - as the idea is once the patch is build, these are the screen you want to ‘perform’ with.

I will say it takes a while to get used to… and ofc, its possible to refine.
in the end I chose one way that was consistent / worked - with the idea, that once I have more users we can discuss the pros/cons of variations to improve.

though, ofc, I want to get it stable first :laughing:

what next?

anyway, Im going to try a few different things to see if I can squash the above issue…

though, Im a little worried, I’ll again fix in one place and it’ll pop up elsewhere.

if it does, Im going to have do try to find a better way to test / debug the issue - but that could take a while, so this ‘quick fix’ is worth a try.

Ive also ordered some more sdcards, so I can create a 100% fresh image for ‘final testing’, as its inevitable a box you use for dev is going to end up with some ‘other stuff on it’
e.g. I have dev versions of perfcmd / trax standalone on mine, plus all sorts of other ‘stuff’ I experiment with. none should impact, but you never know !
but that’ll take a day or two to turn up (here in the mountains :laughing: )

#430

SSP beta 5 / RC 2 is released

looks like issue was a very minor timing issue on deleting Trax to do with module unloading and thread destruction. main case was handled, but seems like there was an odd corner case when there was little to no load.
the light load is probably why it didn’t come up during dev, as I usually had Trax loaded with modules, which would avoid the corner case.

I did quite a lot of testing, with every scenario I could think of (in terms of initialising and de-initialising Trax) and could not get it to crash.
Im kind of confident, except for the fact, I thought last time Id tried everything too :laughing:

the good side, was whilst testing I did re-affirm the previous fixes were required, and indeed it looks like each fix was a step in the right direction, just missing this minor timing problem.

#431

Well you’ve done it again!

( With the previous install)

a) create TRAX , and delete it
Im assuming it will crash ( confirmed)

b) create two TRAX ,
delete one - doesn’t crash (confirmed)
delete 2nd - it does (confirmed)

c) create one trax, bring up UI
now delete - does not crash (confirmed)

d) create two trax, bring up UI on
delete both, does not crash? (confirmed)
create trax, no ui
delete does not crash (confirmed)

(I also ran this same test with the new SSP beta 5 / RC 2 and it functions as intended no crashes so far.)

The issue I was having with the VU meters

Im able to get to them fine by holding the (UP) red button but they just did not show any movement when a signal output was present from trax they were just all ‘grey’ as if there was no audio being outputted on that track even though there was for example plts on track 1 and 3 and i could hear it and manipulate the volume and mute etc.

However with SSP beta 5 / RC 2 this was resolved as well as i can now see movement within the VU meters per track per channel so its all good!

Ill keep testing things out and if i run into anything weird ill be sure to post a comment here just to keep you updated. Ill also give any feedback on the UI since its so new to me its just a learning curve but i may find some areas where it could be tweaked or improved on from a workflow standpoint and if its something you think makes sense to even tackle as im sure your a busy man.

Thank you again for the hard work and have a couple coffees on me mate

Andrei

2 Likes
#432

cool, great to hear everything s working for you too … got there in the end :slight_smile:

look forward to your thoughts, thanks for the coffees, have fun

M

1 Like
#433

ok, as Ive heard of no further issues, Ive moved everything to ‘release’.

if you downloaded the last betas you do not need to reinstall, they are the same.
I’ve also updated percussa.rnbo to reflect latest changes and release as well.

enjoy

#434

a couple of users have pointed out that my midi implementation is not reconnecting if a device has lost connection… so Ive been looking into this for a fix.

dev moves fast, so when I came to compile, my compiler is updated, and incompatible with JUCE.
no worries, just update juce (from 8.0.6 to 8.0.12), that fixes it…

now compiles, but no midi devices !!
investigations, show its an issue with 8.0.12, juce broken getAvailableDevices (possibly more?!) for linux (fine on mac) ,actually it was broken in 8.0.11.

looks like they refactored the midi stuff. basically they seem to be moving to the same approach that they use for MidiDeviceListConnection, that Ive noticed that’s been broken for a while.
this in turn, I think is for their ongoing efforts to support midi 2.0 … so good stuff in the long run, even if it breaks stuff now…

anyways, Ive currently gone back to 8.0.10, and created a patched version, that works with the newer compilers - and I like to keep as ‘up to date’ as possible with juce.

hopefully, in next few weeks / months, juce will fix this, so I can then move to that latest release.

If not, then I’ll possibly move away from juce for midi - not a big fan of it anyway, its pretty bad (imo),

I may possibly consider this now, as part of the reconnection logic, because as above MidiDeviceListConnection is broken, Id have to rely on timers, and that could cause other issues e.g. for brief disconnections.

not sure yet… all in play for now :slight_smile:

3 Likes
GRID Plugin Project - a better 8-channel sampler
#435

Thank discovered this yesterday.

I was using Juce8. And couldn’t get my Midi implementation to work. Even though it’s largely influenced by yours.

So I dropped down to JUCE7 and it worked.

Indeed it’s something with the 0.012

#436

after some experimentation, Ive got a reasonable solution for the midi device reconnection :slight_smile:
(also, quite a few other improvements in midi handling)

Ive also been looking at CLKD and MTIN supporting my ‘midi device page’.
as CLKD is sample accurate, Ive been looking into ways to get sample accuracy from midi.

midi clock has a tendency to be a little ‘inaccurate’, 120bpm, ending us as 119.997, 120.012 etc.
usually the approach is to average, and ‘hope for the best’,
but the issue with that approach is over an extended period of time it leads to clock drift.

but Ive just found, that with the SSP, I can get it spot on… exactly 120bpm, every pulse at 21ms exactly. pretty impressed, almost always with midi over usb, Ive seen inaccuracies.

experiments done, just now need to put this into MTIN and CLKD.

current idea is
MTIN will get
clock and transport out (optional)

CLKD
probably this will be just a new source (Mod Midi?)

in theory CLKD doesn’t need it, as you’ll be able to do MTIN->CLKD(midi), in the same way you can do MIDI->CLKD today, but seems like a nice QoL feature.

4 Likes
#437

clock and transport in ti MTIN sounds really cool.

I use MTIN for basically everything. The module also receiving transport and clock would be extremely handy! :slight_smile:

The midi clock drift sounds like a really weird phenomenon. Do you have an explanation for why it works this accurate over usb on the SSP?

1 Like
#438

it’s your lucky day then… I was just pushing it out the door :slight_smile:

basically this release was for tidying up the midi handling, reconnection etc.
added clock / transport to MTIN, and also to CLKD too.

edit:
you’ll notice Ive moved version number to be the ‘build date’.
whilst having individual version numbers for plugins was a nice idea
however, in practice, they all are built on my own common framework.
so even if a particular plugins code is untouched in a releae, its still very likely to be altered in a release. its also why I release all plugins as one update.
e.g. I only touched MTIN/CLKD, but every plugin this release benefits from the midi reconnection change etc.

also, using date makes it easier to cross reference to changes.

not really, midi clock over usb is a pretty poor on general purpose computers - basically because the usb protocol used, whilst simple is not ‘high priority’ for most OSs, so can get ‘delayed’ - not cool for a sync protocol - add to that the ‘simplicity’ of midi clock, and you get a whole range of issues when you push it, mostly around stability.

the drift thing is mostly a feature of midi clock not having a sync (outside start/stop/continue), even if you didnt have drift from the midi clock. multiple computers will all have natural time drift, (hence why we use time servers)
better protocols, recognise this and so continuously sync - good example is Ableton’s Link protocol, which is designed to be robust :wink:

note: on embedded hardware, and ironically with good ol’ DIN, its not so much of an issue.

this is why people end up using, hardware clocks etc, to try to solve… most of these essentially use audio based on usb isosynchronous protocol, which is high prio/guaranteed (otherwise your sound card wouldn’t work!)
so yeah, general, use audio/cv if you want really tight timing.

in fairness, midi 1.0 is nearly 50 years old, very different time and hardware… 2.0 will sort it out :wink:

not 100%, Id really need to dig into the ALSA implementation.
honestly,I suspect theres a bit of smoke n’ mirrors going on, covering up the midi flaws.
but its certainly working, my timing is better on the SSP than on the Mac, at least in the way Ive implemented it.

caveat:
Im talking just stability here with clock timing, latency and also inter module timing is another thing entirely.
there are a few things that will prevent you getting super tight timing on the SSP.
fortunately, Im more into ambient than techno, so not an issue :laughing:

3 Likes
#439

ok, new release to handle issues with some midi devices

ok, I as going to add this ‘note’ to release, but frankly, most will not see, nor care about it…
but it is kinda important (and useful for me to have a reminder ;)))

some background to midi id vs name change…

tl;dr; you likely wont notice, nor care about this…its can be ‘subtle’

previously, I used midi device name (rather than id), as it meant patches would be bound to a particular controller. and you had multiple attached, this would ensure a particular module could connect to a NAMED device.

however, this had two undesirable side effects
a) most people use ONE device at a time, if you move from one to another, you’d have to reselect the device
b) SOME midi devices name all ports the same thing, so I could not reliably differentiate between them.
Using IDs change this

BUT I hear you cry, does that mean like synthor, you are always connected to the same first device - that sounds limiting.

NO… thats a different thing…
Synthor can only connect to the first port, on the first device
My plugins can connect to any port/device from multiple devices and ports.

one edge case, Im not 100% sure about, that may be ‘limitation’ of this approach (for alsa/linux, not other OSs!), is if you start connecting and disconnecting multiple hardware devices in random orders,
Im not sure they would always get the same id , i.e. device A and device B may get switched.
BUT Im sure if this happens, as alsa may be using an ID based on ‘port’ (kinda like ‘usb port’)

anyway, day to day, this change will be compatible, and ‘feel better’.

the above info, is in case we stumble upon some ‘edge cases’.
IF we find real world issues, I’ll look at a possible ‘hybrid’ solution or one that uses ‘fake’ enumerations. but those are potentially even more error prone… so Id prefer this ‘clean approach’ for now.

2 Likes
#440

hey @thetechnobear I imagine this is documented somewhere, didn’t find it on my initial search. but I want to update Synthor using your latest firmware release where can I find that HOW-TO information and build?

1 Like
#441

yeah, i don’t see it listed anywhere either

#442

what are we talking about?

my release is in the same place as always here, top post has the link.

I suspect part of the confusion here is,
there is no ‘firmware’ for the SSP, it doesn’t exist.
the SSP is not an embedded platform, it has an OS and it has applications (Synthor, Trax, er301 ;)) - no firmware. (the firmware, would be the “bios” equiv for the SoC)

I think often, people treat Synthor as firmware - but its not, that would imply, Traxhost was separate firmware but its not… you can run it alongside Synthor, and ‘hot switch’, no “firmware” update.

anyway, with that ‘confusion’ out the way…
no, I didn’t update Synthor, nor are there any OS changes, my plugins have been updated - thats all.

as for my ‘patched’ synthor, thats a one off (that I will include with releases), but it wont change, its required only due to build/juce discrepancies.

basically, the bug Ras saw was pretty straightforward,
my code was assuming midi controllers had > 1 port . a simple UI confusion, cause by having a ‘fake’ device in the midi ui list (NONE).

the reason, I used a lol emoji against the fix, was the reason the bug exists (and got thru testing)- was I realised out of all of my midi devices (Ive many) only ONE was simple enough to only have ONE port… so unsurprising, I didnt test with it- even though you’d think this was the ‘norm’ for most controllers etc.

the id change was different, that was a real corner case, almost all usb devices exposing multiple ports will name them differently, so the user can ‘choose’ the correct one.
but it appears, at least on alsa/linux, that is not always the case, fortunately, when trying to track down Ras’s issue, I found one of my midi hubs has this ‘oddity’, so thats why I move to using IDs.

note: I did check, this ‘name issue’ is a documented ‘feature’, that is OS dependent.
as above, I can think of a few solutions, so you’ll likely see devs take different approaches, each has there pros/cons, but this ID felt the most ‘honest’ (to alsa) to me.

1 Like