New user here in the PYRAMID universe!
So the copy function when in poly mode should only copy the current notes while in the MONO mode it copies all notes.
This is not happening for me when I just hit the 2nd and copy buttons. Whichever mode I am in all the notes are being copied when I paste them to a new track or new pattern on the same track. Is this normal?
I have updated to the 3.1 pyraOS. I don’t know what the behaviour of the copy function was before 3.1.
Cheers
Kyros
Id say it not quite what the manual implies…
Id log it as a bug…
Will do as you say cause its pretty annoying.
Have to note that If I use 2nd copy and also select the steps then the copy function works as described in the manual.
How is this function is working on your pyramid?
yeah this works, and actually kind of ‘fixes’ another issue I reported to @squarpadmin at the same time
I think, what poly editing should allow you to do is either:
a) paste notes onto the same note as they were copied from (useful across tracks/patterns)
b) paste to a different note, eg to extend the chords
what I found was, basically this works if you do
i) 2nd+copy+pad 1+ pad 16 (so all 16 steps selected)
then,
2nd+paste , gives you (a) … it’ll paste to the same note, regardless of selected note.
2nd+paste+pad 1 , gives you (b) … it’ll paste notes onto the selected notes
pretty cool, so actually all we need is 2nd+copy to be the same as 2nd+copy+pad 1+pad 16
Yes exactly the same here in my PYRAMID.
For a newcomer like me the copy function was a real headache. It took me hours to understand whats going on.
All the above that you describe should be in the manual. The manual in a complex(and quite expensive!) product like this should always be correct and exact.
For example the double tapping of track button doesn’t take you to the trackpatterns mode. Having read whats new in OS releases i found out that there is the step+track button combo that takes you to track pattern mode apart from holding track and rotating the menu encoder which is really useful for me. However all these should be consolidated in the manual.
I hope they fix the 2nd+copy combo to work as expected. Not a big deal but annoying for me.
I will write in a separate post my general impressions, suggestions and other questions that might arise.
Thx for your help, you seem to be a guru around this forum!
I’ve got one last question for you with regard to the core.pyr file.
Do you know if the external midi CC assignments are being referenced and if we can copy them across tracks or channels. Its a very nice feature to use external controllers and assign them to specific CC. But for a multibral machine that uses 16 channels assignment is a pain in the ar…
Cheers
Kyros
actually, most of it is described in the manual… really the above is describing something that appears to be a bug/quirk in poly mode…
(mono mode editing works as expected, and honestly i use mono mode more than poly mode… as usually i want to deal with all events on a step at once)
id recommend if you find errors in the manual you contact squarp, ive found them really good at updating errors/omissions.
the reality is for a small company, its quite difficult to keep manuals up to date, features get added and changed, and its quite easy to ‘forget’ to reflect that in the manual.
you mean from instrument definitions?
if so these are separate from projects, they are not stored in core.pyr
yes, its a limitation that you can only have one definition, it was discussed when instrument definitions were released in 3.0, and squarp explained basically its a memory issue - so they have us the ability to use channel 0 for multitimbrals which is useful, but not as flexible
1 Like
Well in the manual it is described the fact that in poly editing 2nd+copy copies specific events of the current page which as you said its a bug.
But it doesn’t say anything about the paste as you beautifully described in your previous post:
This is what took me hours to understand.
With regard to my question
no I don’t mean the definitions. I am quite happy about them since I found out the channel 0 solution which freed my hands with regard to the multimbral synths.
I am talking about assigning external knobs as described here Pyramid Manual | Squarp instruments
I’ve read the manual better and I realised that you can assign only 120 external CC which are not channel specific unfortunately. So the total is not 120X16 channels but just a plain 120.
I was looking for a way to assign the same external cc to different channels of a multitmibral device. This is not possible.
So I can rephrase my question and hope to get some help from you. Can you copy the assignment of the pyramid encoders from track to track. When copying and pasting a track the encoder assignments are not being copied. Is this possible through the core.pyr.
Thx in advance.
P.S. Having used in the past a great deal of hardware and software sequencers, I seem to really like pyramid!!
when you have the per-track assignments option on in settings, no, the Pyramid doesn’t copy a given track’s assignments to another track when you copy the track. you have to set them up again.
I don’t know if this is a bug or an intentional omission that didn’t make the cut of this “final round” of feature extension. but it is a pain when you make more than one assignment and need to copy a track around.
I’ve also noticed that if you change the output midi channel of a track that has assignments, they don’t follow to the new midi channel. so, for example, your encoder that you assigned to control cc#1 still sends cc#1 messages to the old midi channel. this has to be a bug, and I’ll be reporting it soon.
2 Likes
yes, the per track encoders assignments are stored in core.pyr (as are per project) so I guess you could hack that.
but bare in mind, they only store a reference to the FX slot/parameter - so only going to work well if the track fxs are identical across the tracks.
1 Like
Thank you for specifying the place to find these assignments.
I don’t really care about fx. I am interested in midi cc parameters so I guess it will be easier.
Then again if you want to move a track reassigning the encoders would be drag. I think it is appropriate to copy everything since the assigned encoders are part of the track settings. It is not consistent like the way it is now. Or am I missing something?
I’d encourage you to write to the team about it. it feels borderline bug to me. I understand that maybe the per-track assignments might be locked to the track # and therefore not copiable properties, but the same could hypothetically be said about the midi output settings, fx, etc. it’s fair to expect that all track-specific data would be copied in a track copy.
back to original topic.
so I got a response from squarp about poly mode - 2nd+copy copy all events on the page, rather than just the selected note.
they said, whilst they see the logic in copying just the current note in poly mode, in practice when they tried this behaviour, they found this confusing/less useful than copying all notes. (like mono mode)
so the logic is, poly mode only affects selected events, not a global action like 2nd+copy
they have updated the manual to make this clearer.
whilst Id have prefered poly mode to work on the shortcut, I respect that they tried, and found otherwise,
and I don’t mind too much, as at least Ive now learnt a workflow that works (select via pads and copy)
thanks to @squarpadmin for taking the time to discuss, and improve documentation.
… goes to show if you log things via https://squarp.net/contact, they will work with you to determine if there is an issue, and how things can be improved… even its the documentation.
4 Likes
They replied to me the same thing exactly.
However i think their approach is not consistent. There is no logic that I can I easily understand to this approach.If 2nd + copy copies all notes regardless of the mode (poly/mono) then the same should be for 2nd+delete which thankfully is not. Maybe it is too difficult for them to implement it. i don’t like hearing that in practise it is less confusing cause it really is for i believe the 90 % of people that use pyramid(assumption). There is no logic in it or workflow tactic. I guess that i have to get used to a limitation (bug for me) and get forced to hit a 4 finger operation instead of a 2 finger in order to copy a page of a specific note.
I was really happy to have a copy steps function being an octatrack user which cannot copy series of steps but then again a little frustrated for this inconvenience. I hope they think it again and implement as it should be. would make workflow much more faster and less cumbersome when copying notes between tracks or patterns.
1 Like
I think thats a valid argument…
in my experience consistency is important for UI models, its means the user can make assumption of how things work, based on previous ‘experience’, and so ends up in less memory/reliance on the manual.
so , if there is another similar use-case that is inconsistent with 2nd+copy (like 2nd+delete) then perhaps it needs to be review.
@squarpadmin thoughts?
note: when I logged the issue, I did try to argue the case that I thought only copying the “displayed” was logical/consistent with the rest of the UI.
I doubt that is the case.
unfortunately, as you say thats an assumption…
Ive no reason to doubt Squarp, if they say some found it confusing, then I believe them…
I personally think the mono/poly mode is generally a bit confusing.
partly because at times it feels reversed : MONO mode - acts on multiple notes, POLY mode - acts on single notes!!!
so I can understand if some felt that the scope of mono/poly mode should be limited to entry/selection/visualisation of notes… and the shortcuts might be better (or more useful?) as a global level.
do I agree? - no 
but as long as it is consistent i don’t really mind…
I respect that Squarp has to make 100’s of little decisions like this, and they have to do what they think makes the UI work best, and consistent to their vision - and thats bound to mean a few things are not as I prefer 
Yes i can’t agree more with what you said and this is the reason that I spent so much time to find out how the copy function works but Its not only a matter of consistency. It has more to do with usefulness. Duplication of a copy action between 2 modes is simply unnecessary and also slows down the use of pyramid with regard to note copying between tracks or patterns.This is my main complaint.
For sure the track copy that omits the encoder assignments. Since everything is copied I can’t understand why this being left out.
I am not bitching here. I really like pyramid and I think it is a fast and efficient machine to work with.
For me the things up until now that are missing are the following
- offset for CC messages
- More than 32 sequences. Is it a RAM issue? I would expect sequences to have a very small footprint in ram since they only store track mutes and pattern number. So this is 2 values times 64(tracks) times 32(seqs)=4096(bytes?bits?events?)Again the funny thing here is that we can’t midi control pattern selection.I would make a lemur project to override seq mode but i can’t without the pattern selection.
3)CC external midi learn for CC stepmode like midi note learn which is fantastic
4)CC external midi learn for encoder assignment
I respect their vision too and the fact they are a small number of people that work for this product.
I’ll second that. Took me a good while to get used to it, and I suppose ultimately the brain just flipped the terms internally to make sense out of it. 
1 Like