Request: Definition extensions

#1
  • Allow more (48?) definitions

…so all individual MIDI channels on each MIDI-out can be defined.
I know this might be overkill, but any compromise will always leave some sad users.
Maybe a nice compromise would be to select from ‘many’ definitions while maximum usage is 16 per project?

  • Add optional range and value definitons for CC
    Really, really helpful!

Example for Roland JX-03.
cc#13 = 0 - 5… for… DCO-1 Range = 64’, 32’, 16’, 8’, 4’, 2’
cc#14 = 0 - 5… for… DCO-1 Wave = Sine, Triangle, Saw, Pulse, Square, Pink noise
cc#15 = 0 / 1… for… DCO-1 LFO modulation switch

My current definitions are:
13:O1 RANGE
14:O1 WAVE
15:O1 LFO
…and I still have to look at the device panel to see what settings I can select.
…and I can’t remember if a OFF/ON setting on some device should be 0/1 or (0-63)/(64-127)…?

  • proposal for optional extended CC-value definitions:

My new definitions would be like:
13:O1 RANGE, 0-5, (64’, 32’, 16’, 8’, 4’, 2’)
14:O1 WAVE, 0-5, (SIN, TRI, SAW, PUL, SQR, PNS)
15:O1 LFO , 0-1, (OFF, ON)

With CC definitions like these, Pyramid could limit values for a certain CC (like 0/1 or 63/64) and optionaly show 3 characters of text for each individual value in the range.
I think that the number of optional value descriptions can be limited to 8 or 10 values for each CC. The numeric value will show when there is no description.

  • Optional request for Program Change definitions
    Would be super nice.

Example:
P1:PIANO-01, MSB, LSB

This could be used for factory presets and organized user banks.
The 8-character program name could be shown next to the track name on top of the display.
MSB and LSB for Bank Selection are optional.
The number of Bank Selects for each device could be limited to 16, although 8 might be more than enough for most devices (but not all).

  • Unreal request for Note-definitions per Program change
    I would be in heaven and might send flowers and chocolat to Squarp

Like the current note-definitions, but a seperate list for each Program Change…
Usage: Select drumsets with different percussion instruments from modules with various setups.

I know that some of these requests could be a lot of data (like Bank/Program Changes and extra Note per Program definitions).
I think it’s fine if this data is not continuously in memory, but stays on the memory card and is not loaded until the system has a few milliseconds time to make the info visible … even if it takes 2 seconds … better late than not :wink:

When you have arrived at this sentence while reading, thank you very much for all the attention!

#2

Squarp have asked that al requests and bugs are sent via their contact us page on the website.
https://squarp.net/contact

fyi : the idea of more flexible/more definitions was brought up at the time when they were doing the beta, and Squarp told us there are memory limitations which make this not possible
(this was particularly important for those of use using multi-timbral instruments)

#3

I realize that the data for Program Changes + Banks, and certainly with extra Note definitions, would require a fairly large amount of data storage. If implemented according to my ideas then in the most extreme case you talk about 128 programs * 8 characters * 16 banks = 16kByte for 1 device. If you added all 128 Notes definitions to it (for each Program Change…), it would be approximately 2MByte per device. That is why I suggested using the much slower option that reads data from the flash card during editing / playback, when the system has time to control it without affecting playback.

On the other hand, the extension of the CC definitions should not be such a big problem. When the number of selection descriptions per CC is limited to 8, you are talking about 128 CC * (2 limiting values ​+ 8 selections * 3 characters) = 3.3kB per device … and that is an extreme example where every CC is a switch with 8 positions. In most cases this will be limited to 10 or fewer selectors with 6 or fewer choices.

I was particularly curious how other users think about this … Thanks for your reply, I will consider presenting it to Squarp via the contact form.

#4

I’d personally not want the pyramid to be accessing the sdcard during operation, doing IO is a sure fire way of screwing the timing on a system like this.
( unless it’s designed in front the start which seems doubtful , given it’s not currently done)

#5

Reading the card should certainly not affect playback. That’s why I mentioned those Program Changes with Note definitions as a nice option, depending on the power of the system.

But the more workable CC definitions should still be possible. This is at least something of great importance when composing and editing with multiple MIDI instruments. No one can remember which numbers belong to the selections of a random synth from a random brand.

#6

Unfortunately, that’s a lot of assumptions considering we don’t have access to the source code to know how io and timing is handled, or how much memory is left for things like definitions.

Squarp are the only ones who know the effort required and complications - we can ask, and they can say if it’s possible or not.

Anyway, I’d prefer stable timing at all times (excluding load/save projects) over any additional functionality.

#7

"I was particularly curious how other users think about this "

Not sure this fits in your scope of curiosity, but i consider definition files to be a useless exercise for my rig. I dont use them, quite possibly never will.

#8

I completely agree with you. But the CC extensions wont add much overhead and can be stored in RAM because it’s max 3.3kB in the most extreme case. The CC definitions would exactly as they do now, but those that act as switches will have optional parameters for these switches.

Roland JX-03 for example: 6 selectors with 6 choises each. That is 6 * (2 values + 6 * 3 characters) = 120 Bytes. Then there are 7 switches with 2 positions (on/off). That would be 7 * (2 values + 2 * 3 characters) = 56 bytes. Total = 176 bytes more than it is now. Current size of the JX-03 definitions is 540 bytes for 42 controllers. 13 of these controllers are the switches.

I will send a contact form to see if I can warm them for the CC-extensions. :sweat_smile:

#9

To me, the definitions are very valuable during production. Adding CC changes manually afterwards would be much more difficult if I had to take the MIDI Implemetation of all devices all the time. :wink:

#10

I sometimes use the same CC for different things and decide in the patch what its doing. The same CC on the same multi-timbral instrument does different things depending on the patch.

Say, one CC increasing in value will increase, say volume on one patch but decrease another. I split the same CC values out via a translator, so i just use one CC to achieve that layering.

Most of my synths are from that digital period (?) where unless its 1, 7, 10, etc, it is pgmd in the patch. My DSI stuff might find that handy, but generally everything i want to modulate ive already defined for the mod wheel or the sliders, so i only have to remember 4 CCs.

#11

I wouldn’t call them useless, and can see them useful for some users,

but I similarly don’t really use them anymore,
I think mainly because my setup is pretty fluid… and it also doesn’t work well if you have a multi-timbral instrument and then others… also most of the time, I just record automation, so I dont really care what the CC number is anyway - and can figure it out IF i need too. (just view the midi monitor on the Pyramid)

(also I don’t like the fact, you cannot see the underlying CC anymore, that can be a pain at times, Id like to be able to switch between CC# or names)

I think for it to work for me, Id to be able to load up the definitions on a particular track manually … rather than it be ‘automatically associated’ … but Squarp have explained that is not unfortunately possible.

so whilst in theory its a nice idea, and I do see for some users with more fixed setups its useful (i.e. synths always connect on same channel etC) - its unlikely to ever be very useful to me.

it would be interesting to know how many users actually use it, and find it useful…

i know we all create definition files when it started in Beta, but perhaps many are like @CreepyPants and I, and just found it not that useful in the end - or perhaps the majority use it… who knows :slight_smile:

3.3kb can be a lot in an embedded device that is already short of memory, also you might find they cannot use dynamic memory allocation for this… and if your a developer, you will also know that there is a trade-off between look up time, and reducing memory.

lets also remember in a ‘perfect’ world (and its likely not on the pyramid) , any data used by things like this, potentially eats into the amount of memory for # events - something most pyramid owners are very concerned about.
(also there are other competing requests for memory, e.g. many want the SEQ to be beefed up, in ways that also require more RAM)

also the effort to do implement ranges/enums on CC values is pretty significant, e.g. what do you do when when things are outside these ranges? also the UI space is very limited , whilst your examples are useful in 3 chars, there would be lots of examples where its not…
(I already had difficult coming up with meaningful names for CC# on the Virus… as there is so little space for names - i can imagine it being a nightmare for values)

anyway, I love the idea, but frankly I suspect it highly unlikely to happen - but as per previous post, thats Squarps call not mine (or anyone else here :slight_smile: )

#12

I expect that a device for which I pay more than 700 euros will in any case have plenty MB of free memory instead of a few kB. If not, that is a good reason to sideline Pyramid. At the moment, for example, the firmware contains hardly any extensive editing options. It does not go much further than recording live and subsequently editing a number of parameters. That is also possible with a Raspberry Pi.

#13

+1 for this request. Synth setup/organization with regard to pyramid usage is top priority. Definition files for all gear connected is the goal. Allocating memory for this is more important than new features IMO. I have used up my 16 and still have gear I would like to define.

#14

yes, this is exactly my main beef with the defs. for them to be fixed to a channel makes them more or less useless to me. I do wish I could use them, and I do for one synth, but the limitations get in the way.

#15

its functionality is laid out in the user manual, and there is a community to ask before purchasing,
so an expectation that things dramatically will change is slightly unrealistic. esp. since Squarp have said the pyramid is pretty much complete and they are on limits of cpu/memory. I’d say this is pretty common at this stage in a products lifecycle, especially given the number of updates we have been lucky enough to get already!

so I highly doubt we will see major changes in this area now…

a RaspberryPI has a faster CPU, and more memory , and ?
thats like comparing apples n’ oranges…

as a developer (who develops for the rPI) i’ll say building a hardware sequencer (*) from a rPI is pretty challenging and time consuming - and if you did, you’d start to recognise some of the design decisions being made by Squarp - e.g. there are some good reasons why they didn’t base the Pyramid off (say) the CM3.

Not saying it’s impossible to do, for sure it is (though actually a BBB+Bela might be a better starting point) , but the hardware is not the main cost… it the software dev, thats what your 700 euros is buying.

(*) hardware sequencer - I mean something comparable to the Pyramid, that does not expect a monitor/mouse/keyboard combo… if you want that, just use a laptop!

#16

I have been developing software myself since 1981 and have worked with just about every OS that has been on the market since then. The comparison with rPi is rather between an apple and a bag of apples. The only advantage that the Pyramid CPU has are the built-in AD / DA converters, which come in handy with the CV interfaces. This would require an extra chip at the Pi. So I understand very well that I mainly pay for software development and I am therefore very surprised that the system has hardly any room for further software development. 1MB on-chip flash is so far the only thing I’ve been able to find …

I chose Pyramid to be released from keyboard and computer during composition. That works reasonably well. After that everything just goes to Cubase (in use since Atari ST) for further production.

Anyway … before we get sidetracked, I would like to have this discussion in the field of instrument definitions :wink: