Does anyone other than me feel the lack of such an utility?
Sadly I am not a programmer, but I would like to point the attention of the gifted ones on this major drawback of the otherwise excellent A4’s workflow.
I would really love to be able to move patterns and their related kits between saved global backups to build an ultimate global with the best ones.
I would love also an eagle view of the patterns’ note content
1 Like
I can handle Sounds & Kits, Patterns are too complex to analyze for me though, gotta wait until HQ provides some info how they are structured.
But I agree with you. The scenario you pointed out is a nightmare if there are locked Sounds in the patterns… But it would be easypeasy if an app can actually read the Patterns, and would be able to automatigically place the right Sounds into the right slots etc.
And yeah, this would allow for some pretty cool stuff with generative basslines and what have you.
1 Like
Thnx for your reply void.
I am quite confident that there will be a (not cheap) memory upgrade in the future, that maybe will make the above mentioned tasks more easy from inside the A4. But with the actual limit of 128 patterns/kits one fills the memory quite often, makes a backup, an empty reset and go on filling memory slots. So, before you know it you end up with a fair amount of global backups that are like monads.
Just having the option to backup individual patterns AND linked kits would make managing job, if tedious, at least doable.
ah but this is something you can do right now. In the SysEx Dump menu you have an option “PATTERN + KIT” to send individual patterns together with their linked kits.
Locked sounds are not backed up if you do this though. And yeah it’s a bit fiddly…
Anyway, I did an allnighter last night to take another look at A4 pattern data, and actually did figure it all out. There’s some minor mysteries, but it should be ready soon.
generative A4 patterns, oh yeah baby.
1 Like
Awesome! 
Have you looked at all at the kit/arpeggiator data at all? I’d love to have generative arps or external control over the arps.
yeah arps are part of the pattern. i haven’t generated anything yet, currently writing the code for doing this.
Mind you, what this will be able to do is generate or modify patterns externally, then send it to the A4 as one thing. It’s not live pattern manipulation. I cannot do anything with the pattern that you wouldn’t be able to do by hand on the A4 itself.
So it’s not possible to magically p-lock the arp speed or something…
However, writing patterns using algorithms opens a wide range of possibilities. Random acid basslines for example, or some higher polyrhythmic logic, or crazy spectral stuff by somehow logically p-locking oscillator tunings…
Now, since I already have code for reading / writing MD patterns, I think the first thing to try is something which generates “matching” A4 patterns based on MD drum patterns.
Hey - This looks like a good post to jump into with a related query of my own (ahead of asking the folks at elektron)
I wonder if anyone has had any joy unpacking the sysex dumps. I guess I hoped they’d be readable without processing, but that’s not the case. I’m confident they’re packed in the same way the DSI sysex dumps are (Packed Data Format, see p54 of Prophet08 manual e.g.).
However, short of second guessing and trying all sorts of permutations I wonder if anyone has deduced how long the sysex header is before all the synth parameters are “packed” up, it then ends with EOX 247 (i think the header is appx 14/15 bytes long)
Using a bit of logic i can see roughly where the name is included and if I can ascertain the length i’m sure I can reverse engineer the other parameters, it’ll follow the MSB/LSB numbering scheme in the manual to some extent.
Before anyone asks or comments I do see the benefits of an editor for overseeing how a patch is put together as well as editing sounds with a bit more UI luxury, it’s then easy to do bespoke stuff including morphing and randomizing - it’ll be worth it just to take the tedium out of naming sounds/kits etc
Of course if anyone from Elektron wants to PM me that’ll be cool and it’ll save a load of time.
Then I hope that i can badger them into providing a means to dump the current kit buffer out (either sysex or a full compliment of nrpns) ; - ] please/tack
check out the manual for the Machinedrum, the header layout is explained in the MIDI appendix.
1 Like
Wow very interesting Void!!
I suppose that your finding will have an output in your Max patch.
Any chance to see this as a standalone application or even better as an app one day?
thanks… yeah what I’m working on is for iOS / OSX.
Really the tough part is designing a nice UI for it.
Current state of affairs is, the pattern API can now access everything except p-locks, but I’m working on this right now.
Keek up the good job then!
I’ll await patiently…
@void - thanks ! … the header is a bit shorter than i thought ( by guessing how long the sound data dump was within a kit with four identical sounds loaded ) - anyway, it’s 7. FTR a kit dump has ID $52 (like MD) meaning there are 2636 kit data bytes to interpret. Interestingly the A4 sound dump uses the MD kit req ID $53(83dec) there are 412 useful sound data bytes to explore. None of the sysex dump requests worked for me, so it seems to be limited to ‘on machine’ dumps for the moment. The A4 has an ID of 6 btw.
Am i right in thinking it’s a “packed” data format then :-?
1 Like
yea it is
Be careful with A4 SysEx experiments. There is a hidden command which will break your CV outputs and requires a factory calibration in Sweden. Guess how I found out.
Anyway, do not send command 0x7C or 0x7D.
Afaik, the dumps for sounds, kits, patterns, songs & globals are the only useful messages available.
2 Likes
wooaaaoouch - thanks for that tip (& confirmation) !!!
i had been experimenting a wee bit !
i’ve actually just confirmed the packed data layout to some extent
for the sake of sharing (for sounds) …
There’s seven bytes of header, a pair of 1s then the sound slot number … then there’s the packed data (404 or 405 bytes in length) a 4 or 5 byte long checksum then EOX
So far I can see that the Osc params are sent in pairs ! Firts two bytes are MSB LSB for Osc 1 encoder A&B, then the same for Osc 2 the 5th and 6th bytes are detune Osc1 then 7/8 is Osc2 detune (ie enc C) and so on
The name is sent towards the end just as 16 MSB vals
that leaves a few gaps which i can keep tweaking away (slowly) at unless you have a better idea !! ; - ]
(I’ve just asked at Elektron for a heads up on this too)
so what’s the target length of the usable packed data (353~355?) and the starting length (404/405) … just askin’ ?
(the last letter of a sound name seems to be the 353rd byte ! is that the end of the data)
thanks for the infos
cool, you seem to be working that stuff really quick. I can’t share anything more specific because [redacted].
Rest assured, I haven’t gotten much more info from Elektron than you have: The A4 OS is still in development, and there likely will be documentation once it’s considered ready.
Personally I’ve mapped it all out by tediously tweaking encoders, dumping sounds, and comparing the dumps in a hex editor…
But yeah, if you haven’t done so yet, please send them a feature request for a comprehensive SysEx implementation
gotcha ! … i’ll poke around a bit more, it shouldn’t be too tricky to map it out with careful parameter settings, hopefully there’ll be some official assistance by the time I look further into the kit layout although the broad layout is clear … all this number gazing is time away from playing anyways !
I am trying to make an app for managing and manipulating presets with a signal chain visualization. Do you care to share your sysex mapping results from your tedious work? =)
Ah yes, I found this after I posted the question. This is great work! Not to mention a LOT of work;) This is exactly what I needed. I didn’t get too deep in the code yet, but I had a few questions.
I see that you are able to query the current “focused” track and then query the sound settings. In general, do you just constantly pole the A4? Is there a way to have it be event driven when you change focus on the A4(track, synth, LFO, etc…)?
hey,
nah the A4 doesn’t send out such events but it would be cool!
it sends when a track is muted via CC or NRPN but for everything else I haven’t found a better way than querying the entire structures containing the info you want (settings, kits, sounds, patterns etc…)
e.g. if you want to change the sequencer tempo, you ask for the Settings object, then change the bpm in it and send the changed Settings back… it works quite well with the caveat of cluttering the MIDI connection with a lot of sysex data.
usually I don’t poll the machine all the time, and request the info only when it’s necessary…
in one case, a randomizer, I want to display a different UI when the FX track is selected, so there I request the Settings 4 times each second…
super inefficient, but whatcanyado? 