Problem calling an instrument with a definition file

Newbie here … Just registered. So hello everybody ! :slightly_smiling_face:
I love my pyramid !!

But when I created my CC/Notes definition file with 2 instruments: a synth and a drum- machine on the SD card, some problem occurs.

The Pyramid recognizes the files when I do 2nd+TRACK and I select CALL. It shows my 2 files names.
But when I select one of the instruments (making sure port and MIDI channel are the same than on the file) using the top encoder and clicking on the instrument, nothing happens !! The track doesn’t get renamed, in fact it’s as if no instrument got called.
Also when I go to STEP and to CC messages mode, the CC list shown is the default list and doesn’t reflect my instrument CC list at all.

What’s happening ??

Welcome to the forum!

Some ideas
-I had some issues when using my first def files. Make sure you use the title def.txt for the file name. I named it something else and had problems.

-have you checked to see if someone else has created a definition file already?

-Also, are your text definiton files using the same MIDI channels as your synth and drum machine?

Hope some of this helps!

Best way to debug this is for you to post your definition file. It may be malformed in some way, and/or we can try loading it ourselves to see whether it works for someone else.

Yeah, by the sound of it there are about two things that can be wrong: either the definition files are not in plaintext ASCII format (you need to use a text editor, not word processor), or there’s some sort of syntax error in them. The Pyramid is not too helpful in diagnosing these problems, if there’s anything wrong with the definitions they just silently refuse to work.

1 Like

Thanks to all respondents !!

Yeah, maybe it is because I am a newbie with Pyramid, but I had lots of trouble getting my description files to be read by Pyramid, even though I made sure to use plain text (.txt files), and align correctly port and channel number.

I finally did get success by trying up several definitions files found on this forum (doesn’t matter if one actually has the gear associated with them). Lots didn’t work for me (ie were not read by my Pyramid), but a few did !

So I took 2 of these files that did work, erased the content, and pasted in these files the text corresponding to my gear. And finally after a few adjustments got these files to be read by Pyramid !

My only explanation at this point is that when I started from scratch, somehow my (old) Macbook maybe inserted some stuff in the .txt files that confused the Pyramid parser.

By the way, I found the Squarp team in Paris to be really helpful and responsive. I want to thank them here. :slight_smile:

And as I said earlier I do love my Pyramid. Magnificent machine !

A .txt extension doesn’t guarantee ASCII text in any way, it’s merely a convention that can be broken in any number of ways.

The manual recommends using TextEdit on the Mac, and Notepad on Windows (

Mac texteditor used rtf by default
Convert to plaintext and youll be fine

Hey @909_State, I found a bug in PyraOS V3.23 which may explain your issue. With this bug, if two instrument definition files (a_inst.txt and b_inst.txt) have the same midi channel, then no matter which one you select, PyraOS will always load the one which is alphabetically first.

Sounds to me like maybe you were selecting, say, b_inst.txt and a_inst.txt was getting loaded. This can be especially puzzling if you forget that a_inst.txt is on your disk and specifies the same midi channel as b_inst.txt.

I will report this bug to the awesome Squarp team, who have made my all-time favorite piece of gear. I freaking love my Pyramid!

Thanks for the post, but all my def files problems have been since resolved with 3.22 and 3.23. Apparently the issue was formatting. The problem apparently, is that sometimes creating a raw, pure .txt file is not so easy as one would expect. :slight_smile:
As far as channel specifications I remember that each instrument I was using had its own channel, and I made sure there was no overlap.

1 Like