ok, I’ll bite, what do you want to say about editors?
what specifically would you want an editor to do?
(I assume you mean running on a desktop/computer?)
here is my take:
(I have actually looked at this before, as a developer Im always curiosity about possibilities!)
the midi data is already editable in a DAW that support midi type 1 files.
this was improved for v3.0, but I’ll be honest Ive not really dug into this much since the release. but what i did try worked really well
I personally would not be interested in creating a midi editor, its quite a task, and DAWs already do it a lot better than some ‘knocked up’ editor would do.
sure this is possible, but this is pretty easy with a plain text editor already, cant see much advantage…
project parameters/track setup
ok, so these exist in a plain text file called core.pyr
its contents is pretty simple to parse, pretty simple name/value pair stuff.
the difficulties/time consuming stuff are
handling different OS versions…
id not even touch this, as its a minefield of compatibility issues, and lots of code to handle alternative versions.
determine all the keys, and what they are used for…
the main ones for settings, track, patterns are pretty simple, but some you need to use the ‘feature’ to see (e.g. custom chords) - so thats research.
its not too problematic though, since as long as you leave ‘unknown’ keys untouched when you write the file, then the editor can be used just for whats it does support.
what key values mean?
so all key values are numeric, so in many cases the meaning is pretty obvious e.g. TR>01_Channel:0 means track 1is using midi channel 1… BUT often the values are enumerations, which are dependent on a couple of things
this means the 2nd fx slot on track 2 is a randomiser, (FX2:6) , set to octave (P01:1) with rand- = 53% (68/127) , rand+ =100% ( 127/127) … P05 is irrelevant here as randomiser doesn’t use it.
so this is the difficult one , for an editor you’d need to go thru each option and one by one decode them.
this is made much more time consuming since to do this you need to:
a) go to pyramid, set up a track to ‘research’ options, save project
b) unmount card, mount on pc
c) open up in editor, review changes
then repeat this for every combination…
its very possible, but just quite time consuming
if/when squarp released a new version of the OS, you would have to review it all again, since the file format is ‘private’ they are at liberty to change it. so it could create a little or alot of work to update it to a new OS.
ok, I think PyraOS now pretty much ‘finished’, so likely to be only small options for tinkering now.
so thats pretty much a summary of what would need to be done/viability.
its possible, but quite a bit of work…
so lets talk about why?
what would doing this actually get me?
I cant really see it helps much… the UI on the Pyramid I think is actually really good.
also I think popping out the SD card to have to edit this stuff, is a lot of effort for no huge gain, so its not a great workflow - lets be clear here, you cant ‘add functionality’ to the Pyramid by doing any of this.
I think the exception to this is editing midi data…
if you have a large number of complex tracks, then editing on a high quality daw is going to be much easier, they often have a lot of sophisticated tools for editing, and of course you have a much bigger screen
but this is already possible by just editing the midi file, you dont need an editor!?
what do you think an pyramid editor is? what would it do for you?
so i don’t really see it as blasphemous, but im not sure what you are hoping to achieve!
if I didnt want an editor… why did i previously research the core.pyr file?
well, as stated above I’m curious, but also because it reveals quite a bit about how the pyramid structures things internally, and how it works… and in particular I was interested in what data was stored per patterns vs per track
I was also vaguely interested in what might happen if I created pattern alternatives in a daw, and saved as midi type 1, how could I make these available on the pyramid.
really really off-topic… blue sky, never going to happen!
so amusingly, I can see a much better reason for understanding the Pyramid files.
to create software that could play back pyramid projects on your desktop/raspberry pi…
this could be kind of fun, you could develop the project on pyramid hardware then move it over to somewhere else to ‘play it back’, by interpreting all the settings you’d be able make it playback pretty convincingly.
(ok, you’d have to either reimplement the midi fx, or interpret as midi vst parameters, not easy, but not impossible)
Ive no intention of doing this, way too many other projects, rather it just occurred to me when I was wondering why you’d want a desktop to be able to understand the Pyramid project