To your initial post. I now understand what you were saying. I think it’s basically something that we as users are going to have to be aware of and maybe work around if necessary. Yes… It’s kind of weird… But I get the impression it has to do more with how the midi spec itself is built.
It might be possible to fix… But as a lay person… (with very good software/hardware diagnostic skills) I wouldn’t know who to direct the query to… Is it a Reaper export issue? A pyramid import issue? Both? Neither actually considering the implementation of both?
I’m just happy I know how it works now… So, thanks for the motivational push.
Out of curiosity, had another look at what the spec says about them files:
0 the file contains a single multi-channel track
1 the file contains one or more simultaneous tracks (or MIDI outputs) of a
sequence
2 the file contains one or more sequentially independent single-track patterns
So actually Type-2 would be the appropriate format for the Pyramid’s use-case for storing patterns. As to why it uses Type-1 instead of that, I can only speculate but I’d guess it’s for interoperability, Type-2 support is probably exceedingly rare.
Surprisingly this doesn’t seem to have come up here before.
yeah, buying BWS just for this would be kind of ‘extravagant’
but I like BWS for its sound design (modulators) , and ‘The Grid’ is fantastic, especially when used with eurorack (cv stuff is great)
that said, I like Live too esp. with Push … Live 11 is excellent, and finally has MPE support - which is why I bought BWS initially when it came out.
yup, thats what happend with bitwig when I tried (1.5 years ago… but I guess thats not changed) - Im pretty sure I reported it to Squarp - around the time they did some improvement on type1 support.
that was my thoughts, but it appears Type-2 is even less supported than Type-1
Despite reasons and since there is currently no ‘fix’ other than using a different software, what are our workarounds?
In my case when I ran across this a couple years ago, I decided that I could:
Copy/Paste after loading to Pyramid to ‘fix’ empty Pattern01 slots. In constructing my MIDI Files for export from my DAW, I put what would be the 1st Pattern into the last MIDI Track, and then after loading onto the Pyramid copying the last Track to the First. Note: I didn’t have >16 Tracks. Do Type 1 MIDI Files accept more than 16 Tracks?
Expect Patterns to start at 02 and use Pattern 01 for a different purpose. Since the above took extra steps, I instead opted finally to just use Pattern 01 to ‘set up’, that is sending MIDI CC07, CC10, and any other CC’s that I may want my devices to have before the song actually begins.
Don’t use Patterns. Honestly I gave up on using Patterns. They are VERY powerful, but not accessible via MIDI and that’s a deal breaker for my workflow.
As always, mentioning this to Squarp may help in the future. squarp.net/contact
I have a wholly superstitious and ignorant opinion that the problem is in the .mid header info as I find that viewing files created in different DAWs have different extraneous info.
If someone can point me to a midi file which behaves this way (pattern offset off by one) I can certainly take a look to see if there’s something more-or-less obvious that could be easily stripped off with a little script or something.
the one on the pyramid … is presumably the one it is expecting.
remember: the pyramid is using this as its native format, it is not importing/exporting them
yeah, I could compare bitwig output with the internal one on the pyramid.
if I can work out the difference I can ‘file’ it with Squarp, and perhaps they can consider a change.
the concern its, given its their ‘internal format’ that might prove difficult.
(but personally, Id want to avoid scripts etc, thats a faff )
EDIT : I should say, I half-remember, previously sending an example file from bitwig to squarp to take a look at… but I didnt follow up on it, as I wasn’t using ‘day to day’
LOL@me
Sorry, my brain doesn’t work anymore.
Yeah - and here I msg’d pmatilai a Type1 .mid file that imports as we’ve been discussing - but it wasn’t created on the Pyramid.
Looking at a specimen @CreepyPants sent me, I think the issue is meta-events that appear before the first track declaration in the file (tempo, time signature etc which Pyramid stores elsewhere) which end up being belonging to an unnamed track, throwing the all the named ones off by one. Didn’t have a chance to test this yet but seems fairly obvious. It should also be quite easy to fix in Pyramid, really.
I’ll report this to Squarp once I have a chance to verify my theory.
I think I’ve sent in a feature request for patterns switchable through midi… I just hope that with the dev budgeting they need to do it eventually finds its way in.
Hmm. Reading up more on the MIDI spec, Type-1 files are actually expected to have this “track 0” which contains all that metadata which Pyramid stores elsewhere. Some implementations add a track start header for it, others apparently forget, but that’s besides the point.
On the outset it should be easy to ignore a track with only meta-events in it, but not knowing how it’s implemented on the Pyramid and what assumptions it makes… I’ll withdraw any predictions on the difficulty.
)