Over time I’ve done quite alot of messing about with integrating the SSP with various DAWs and things like VCVRack.
however… I keep ‘forgetting’ some very useful information, which I need to write down, and thought I’d share here.
some of this I might need to validate again, as its from memory… at the moment its a bit of a brain dump, but could be useful for discussions - I’ll try to expand on this over time.
note: this assume you are on the latest SSP firmware, which had some important changes in this area.
the SSP is a midi usb host, so you cannot connect directly to a computer. since it is also a USB host.
if you want to connect, basically to eitehr
a) a usb midi hub + midi din converter
e.g. I use a cheap usb -> midi din cable + blokas midihub , but lots of alternatives including iConnectivity
b) use a usb host to host converter
(this is NOT just a usb A to usb A cable - that will not work and possibly cause damage)
a few options Ive used sevillesoft usb to use (as its cheap, does what its supposed to)
Clock, bare in mind computers do NOT priorise midi data, since its usb serial - this means you will alway gets some drift/jitter - this will cause bpm to shift.
this is entirely normal! (though some computers/operating systems are better / worst)
This is pretty obvious. connect a usb cable and SSP acts as an audio interface (24x24)
you can set sample rate and buffer size - just like any audio interface using 48k is less processor intensive on both SSP and your computer (I only use 48k!)
the main ‘gotcha’ here is remember that there is always latency.
latency comes from the processing buffer size, and also the physical transfer of data over usb.
we also have latency from the operating system
do not think it will just be your ‘buffer size’ you set in your daw… you will be very sorely disappointed, there are quite a few buffers required, when you start doing audio processing.
really the best way to test this is to do a ‘loopback test’
why do we care about latency?
well if you have audio coming from the SSP (or going to it) and you want it to align with audio generated locally, you are going to have compenstate for audio.
all daws support this, but too complicated a topic for here (sorry) !
remember - latency is present in every digital system (analog as well, but a bit different as it doesnt buffer), its just something we have to learn to deal with.
the good thing about audio latency . is it is constant, it does not have jitter.
the SSP audio interface is DC coupled this means that we can CV over it as well as audio.
The first important part to remember is like audio (see above) - CV is not ‘instant’ , being an audio interface means we have audio processing buffers.
Generally MIDI will like be processed quicker than CV (!), this its less data, and also it does not get buffered.
why use CV at all then?
a few reason
a) it does not suffer jitter , the delay is constant (like audio)
b) if you are sending audio, it will be aligned (since it has the same delay)
c) it is higher resolution - its sent as floating point 32 bit , where as most midi is often sent as 7 bit!
like most things in life, there are benefits and drawbacks to both
CV in Daws and things like VCVRack
this one catches me out time and time again (mainly why I wrote this post )
CV is sent as audio , which is nominally -1.0 to 1.0
now we know the SSP also represents CV in a similar way. and since the SSP is -5 to +5v CV input, it maps -1 to -5v, and +1 to +5v
this is entirely logical
however, there is no standard for this!
In Bitwig , when you bring in CV from an audio interface , it as an option to specify the ‘voltage range’
(bare in mind its entirely arbitary)
However, VCV Rack assumes its +/- 10v !
when this really hits us is when doing v/oct , since it means vcvrack doesn’t track properly.
its simple to solve - just introduce an attenuate and halve the voltage! (multiply by 0.5)
(its all digital, so it will be accuate!)
note: since the cv/audio is transferred digitally - calibration should not be an issue.
(unlike when we go out through the ADC/DAC of the SSP)