Novation Peak - notes latching on

Pyramid
21

I’m personally experiencing constant break ups of my creativity with that sequencer.

I think this machine needs a major update. From a better midi files import/ export for midi edition in the DAW, to editable start-stop behaviour on choosen patterns (when pressing SEQs pads), to pads assignations editable parameters (for mute or for keyboard), to memory!, to multi project editions, to ergonomy, to differents multi effect for multi tracks… I got hundreds of ideas. Things that already exist here and there, since the 90’s.

Acutally the only thing that works fine is the long song programation, and the program changes (and not even all the time). Also the elegant compact design and the light weight is a plus. The pad works… but we touch it once a month… It should be replaced by contact buttons and rotators

Otherwise I constantly have to think, to understand how it was built, to remember hiden fonctions. and I CAN’T improvise, I CAN’T free myself. It is very frustrating… Some issues are not just absurds, they are almost criminal. The time we loose on this !!!

The thing is that none of the actual sequencers allow you to create long free patterns in parallel of small one, and it was for me the reason I bought that machine (and the small size).
The very good old sequencers are too heavy (like the RS 7000), and nowadays too fragiles for the stage. Ableton is NOT an option. Octatrack or TR8s are also not satisfying options. Arturia is a small loop toy. Pioneer sequencers have limitations.

So we are in 2022 soon, and the world has no decent midi sequencer that fit in small case.

Something to PROGRAM complex music and decents 2 hours live acts entirely with the machine, in a snap, and to PLAY with the machine, to re-intepretate what is written, fast, and deep in the structure.

22

I’d suspect this is very unlikely to happen… Squarp have previously said they consider the product mature, and there is only limited resources (cpu/memory) left for enhancements/bug fixes.
(and we have no idea, if Squarp plan to create a followup to the Pyramid or not)

anyway, I think your post is a bit off topic, as I don’t think its related to specific issues mentioned by the OP.

23

This is absolutely IN TOPIC, all MIDI issues related, or MIDI weaknesses. I can apologies for my words, but I’m trully experiencing real absurd difficulties. I’m loosing time and energy. I’m composing as if I would live in the 80’s. The company sold the device by saying : midi files dialog, infinite possibilities, and so on. It is simply NOT TRUE.

Note that the only way to work in parallel with a DAW and to re -import midi files, is to … make it separately, by individual patterns, and to change the name, and to reimport it on a blank pattern slot, and then to copy paste it where you need it. Like… I’m trying not to have a nervous breakdown right now.

24

no…

as, I stated previously, detailing every midi issue, wish , weakness under ONE topic is absolutely not productive… particularly for a midi sequencer, as it would basically just become a dumping ground for any gripes people have - a hotchpotch of unrelated issues and thoughts , which adds no value for anyone.

( I will end up closing this topic if this is the way it goes)

if you have particular things you want to discuss, then create a topic for it.

also a reminder that bug reports and feature requests should be posted via the contact form,
as detailed in this post

as for your specific comments (excluding import/export) its hard to know what to suggest…
no device has ‘infinite possibilities’ , they all have specific workflows, and strengths and weaknesses, and as I already stated, its a mature device - its unlikely to change radically at this stage in its lifecycle.

fortunately, today, we have so many resources (specs, manuals, reviews, YouTube tutorials, this forum! ) for our purchasing research to help decide if a product is going to suit our needs before we buy.
of course, its not 100% guaranteed that we won’t get a mismatch, but its better than ever before.

at the end of the day, some things will be a better fit for some musicians that others, we all are (thankfully) different, and have different needs/ways of working … so for some the Pyramid matches well (or well enough) … for others its might not be a good fit.
if its clearly not working for you, and is causing frustration, Id just move on… find something that fits better…
I don’t know what would meet your requirements (and its not really the place to discuss) , the only other really comprehensive midi sequencers I can think of are the Midibox Seq v4 and Cirklon - which you could research.

25

I assume you are on the latest OS?!
if so , please report via contact forum… squarp have been really good at fixing these kind of issues in the past.

I guess things like the UI bug you mention (non crashing) we just work around.
though I cannot think of things I particular have to workaround offhand…

I guess, mostly if things don’t work as I want/expect, I usually just send a FR to squarp, and then find a different way.
I can think of a few outstanding FRs I have on the Hermod e.g. about clock, can’t think of one on pyramid… but im sure there must be one or two.

the most obvious limitation I know of is the ‘import/export’. … I gave up on that a while ago, after I did a lot of testing, and sent those findings to Squarp… I just decided I would not use a daw for editing.

at most, Id just track the midi into Ableton sending 16 things at once via different midi channels, meant it didn’t take too long. (though if you have many patterns its going to be a bit of a pain)

( I didn’t really like the whole thing of removing the sdcard from the pyramid anyway… and playing with its midi… it felt like it was always going to be a bit ‘fragile’ - so wasn’t really a big deal for me)

but then again, I don’t often want the midi from the pyramid in my daw…

so again, comes back to what my post above to stalker said.
whilst there are limitations, it works well enough for the pyramid to be useful/enjoyable for me.

but I can understand that for others that have different workflows there could be problems.
the choice is then to adapt your workflow/requirements of the pyramid … or I guess use something else.

26

Mod note: Ive change the title of this topic to reflect the original posters problem.
please keep on topic.

27

Hi Stalker and also TechnoBear,

I think this conversation is meaningful and important. The OP was Frank, and he says he has given up and returned his Pyramid sequencer due to the stuck notes issue. I have what seems to be the identical issue and it is messing up my workflow, although it does not mean I have no use for this sequencer. Dewaldo has what sounds like the same issue.

Stalker, I feel that your issues are legitimate and also quite different. Reading your post carefully, you seem to be saying that the user model is not a good match for your application. And… fair enough, but there may be nothing that the Squarp team can do about that.

Sometimes bugs cannot be fixed. There is a product that I love, a synthesizer that is nearly perfect, made by another company. And something came up when they released it that was a really basic bug, and they can’t fix it because fixing it would make the synthesizer sound worse on most of their existing patches. These kinds of situations happen. It is like that with the user model of the Pyramid. You can love it or hate it, but the company can’t change it completely at this point without making things very difficult for people who have fully internalized the existing model.

The software part of Pyramid is a complicated thing. Hardware user interfaces seem like they should be simple compared to desktop software, and sometimes the opposite is true. Sometimes when you write a big piece of code you are able to do it in a way that there are almost no bugs, but much more often that doesn’t happen. We are much more sensitive to bugs in a simple hardware user interface than in a complex desktop user interface. That is usually because they have higher impact on our use of the machine! But there is also a more subtle thing about the way we perceive a physical machine. I have personally experienced this as a software developer, and I suspect you have too TechnoBear.

Anyway maybe “future sequencer features” really could be another thread, or “how to use the Pyramid in live settings” would be a different way to go about it. I do feel what Stalker is saying in my own use of the Pyramid and would be happy to continue the conversation if there were some way we could communicate privately, or anyway off of Squarp’s support forums. Stalker, say so if you wish, and I think we can get the board admins to put us in contact with one another. Or let me know some other forum where we can discuss some of this.

I do want to plead that this basic bug related to stuck notes should be fixed. I’ve provided a way to reproduce it easily that anyone can perform. It is clearly a problem serious enough that people have given up on the Pyramid because of it. And it should not be a fundamentally difficult thing to fix at my best guess. I’d be overjoyed to know that some other piece of equipment in my setup were at fault or that I’d made a usage mistake, but I believe I have logically excluded both of those.

If this is a thing that just has a lot of bugs left, as it feels like to me now, I think there is really high value to Squarp in fixing the bugs even if it feels vey painful. Sometimes you have to rewrite things a bit to make it possible to fix the bugs, but this can be done, and the result is usually smaller code when you do it that way. This machine is very close to being a complete game changer for me. It is possible that I will learn to ignore the bugs and get more value out of it over time. It probably could never be safe in a performance setting given what I’ve been seeing, but I’ll be happy if I can use it in composition for now. And we might not be talking about a ton of bugs. Maybe there are ten really serious bugs here, and I think I’ve personally seen about five. This is only a guess, but it may be that if you completely resolve the ten most serious bugs that it completely changes the future trajectory of the product, because you will enable uses that are simply not possible now. This has worked for other companies in this space, even for one other tiny sequencer company that comes to mind.

28

Thank you Technobear for this (quoted below). It seems reasonable. It hasn’t been my workflow, but I’ve been thinking about doing what you’re talking about–live capturing MIDI from Ableton and then live capturing MIDI in Ableton from Pyramid as a way to extend the workflow that also makes the process less sensitive to user interface bugs.

I am indeed on the latest firmware for the Pyramid. I’m curious whether Frank’s problem and the problem observed by both myself and Dewaldo are really the same. The only difference is that I’m using an external controller whereas Frank was using the pads on the Pyramid. I will try to reproduce the problem as reported by Frank–that is using the pads (and possibly MIDI effects) rather than the external controller. This is an intermittent problem that seems to happen randomly. I reproduce it with the external controller by using the external controller’s arppegiator. Perhaps the MIDI delay effect can take the place of the arppegiator for testing with Pyramid’s pads…

I guess things like the UI bug you mention (non crashing) we just work around.
though I cannot think of things I particular have to workaround offhand…

I guess, mostly if things don’t work as I want/expect, I usually just send a FR to squarp, and then find a different way.
I can think of a few outstanding FRs I have on the Hermod e.g. about clock, can’t think of one on pyramid… but im sure there must be one or two.

the most obvious limitation I know of is the ‘import/export’. … I gave up on that a while ago, after I did a lot of testing, and sent those findings to Squarp… I just decided I would not use a daw for editing.

at most, Id just track the midi into Ableton sending 16 things at once via different midi channels, meant it didn’t take too long. (though if you have many patterns its going to be a bit of a pain)

( I didn’t really like the whole thing of removing the sdcard from the pyramid anyway… and playing with its midi… it felt like it was always going to be a bit ‘fragile’ - so wasn’t really a big deal for me)

but then again, I don’t often want the midi from the pyramid in my daw…

so again, comes back to what my post above to stalker said.
whilst there are limitations, it works well enough for the pyramid to be useful/enjoyable for me.

but I can understand that for others that have different workflows there could be problems.
the choice is then to adapt your workflow/requirements of the pyramid … or I guess use something else.

29

Squarp have explicitly asked that feature requests are sent via the contact form.

there are already topics on this, Id recommend reading these, and then expanding on ideas on them.

if the has been sent to Squarp… then I cannot see what else can be done.
Squarp devs are then only ones that can fix this issue… assuming they can reproduce it.

you should be able to use DMs on this forum

though this ‘feature’ is dependent on trust levels - basically, if you have been active on the forum, then your ‘trust level’ is higher, and you get more features available - like DM

if you click on a users profile (icon) then ‘message’ will be an option, if you have sufficient ‘trust level’.

I recognise we all like to share issues to see if others are seeing the same thing,
and you will see on many posts, I even try to replicate… to see if I can ‘add anything’ that will be useful to the poster, or for the bug report that goes to squarp.

but there are limits to what can be done by users here… at the end of the day, as I stated in my previous linked post , ultimately Squarp want bug reports/feature requests via the contact form - rather than here buried in discussions.
(and they have asked us ‘mods’ to request users do this)

Squarp will then use these reports, and contact the user directly to get more info, they believe this is more effective than reports/discussion here on the forum.

ultimately these things come down to what the Squarp devs believe can/ should/ need to be done… this is better done directly with them … since no matter what others think here, it is only Squarp that will ‘action’ the request and have the information to know if what is wanted is even feasible (technically or economically)

rather this forum, was created as a community forum, we use it to positively help each other.
you will find many instances (including earlier in this topic) , where community members help others to find solution to their issues, or diagnose an issue, or suggest ways to use the pyramid.

that’s the reasoning, agree or not - its Squarp’s choice how they wish to conduct support, and so ultimately how this forum is used.

indeed, but sometimes in software , its easy to confuse cause and effect… just because a problem (effect) looks similar doesn’t mean they share the same cause.
so, both problems need reporting to the dev as separate issues, so when devs ‘fix’ one issue, they will then test against both bug reports to check that it fixes both.

regarding testing, this is another reason to be using the contact form. when Squarp fix bugs, they will often contact the reporting user and supply a ‘beta’ so that they can test that the bug is indeed fixed…

this is an important step for something like the pyramid, since users have setups and equipment that Squarp do not have access too - so the bug needs to be verified as fix in that reporters case.

30

A post was split to a new topic: Mono/poly handling

31

I have a P12 also and was going to see if I can duplicate your scenario. I just wanted to get clarification since I don’t experience these stuck notes.

You note you have nothing on the P12 DIN MIDI In, so the P12 arp is sending out MIDI to the Pyramid which is then routing to a different synth…? Did I miss what synth this is? Or are you running the P12 Local: On and trying to record (only) the arp events on the Pyramid?

Normally I use the USB MIDI on the P12. If you have a chance to test it, do you think you might be able to see if you duplicate via USB MIDI, either Pyramid or P12 or both? I realise not everyone has that option, just want to check.

1 Like
32

Hi

Ive not been back to this post since I last left a message, it seems to have grown!

Just thought I ought to give an update, and that is I returned it in the end for a full refund! It displayed signs of being faulty, and having had issues with equipment from other manufacturers in the past, I did not want to end up stuck with it if I tried to persevere and work through it.

As I stated in my first post, the issue was not only related to the Novation Peak, it was replicated with other synths as well, those being an Arturia Microfreak and Behringer TD-3. The issue occurred when using MIDI ouput A, not B, and what was odd was the TD-3 would not receive MIDI messages with either output.

Reading the replies seems to indicate that these issues may occur even with a new one, so Im not sure how keen I am now to re purchase.

33

Thanks! I will try with USB MIDI from the Prophet 12.

Did I have to use local:ON from the Prophet 12 to get the arppegiator to send repeated notes? Yes, I think that was required. I made a special patch that doesn’t make any sound for this purpose.

And yes there is another synth on the output side, a Kodamo FM Essence. But it seems not to matter what the synth is. I never get stuck notes if the P12 is directly connected to the Kodamo, and I can observe the problem behavior purely from the Pyramid’s MIDI monitor without knowing what the Kodamo is doing. The siutation I’ve repeated using the arpeggiator is:

P12 (DIN MIDI OUT) → Pyramid (DIN MIDI IN) → Pyramid (DIN MIDI OUT A) → Kodamo FM Essence
[In these tests there were no other MIDI connections. I removed all other connections so that I could not be fooled by some MIDI loop behavior. Also in this case I know from Pyramid’s MIDI monitors that the controller is just sending NOTE_ON, then the Pyramid sends NOTE_OFF, NOTE_ON, then the controller sends NOTE_OFF, then the Pyramid sends nothing. In other words, I don’t know what causes the Pyramid to get into the state it gets in, but once it gets into that state the P12 is not doing anything unusual that I can detect and the problem does not interact with the Kodamo at all because it is observable in the MIDI event stream reported by Pyramid.]

I believe I have also randomly seen this problem with:

Subsequent 37 (DIN MIDI OUT) → Pyramid (DIN MIDI IN) → Pyramid (DIN MIDI OUT B) → Subsequent 37 (DIN MIDI IN)

P12 (DIN MIDI OUT) → Pyramid (DIN MIDI IN) → Pyramid (DIN MIDI OUT B) → P12 (DIN MIDI IN)

These last two observations are not 100% reliable because they are from just a few experiences, and from my memory of times before I’d understood what was happening in any kind of consistent way. Since you’re also trying to reproduce the behavior now, I’ll try the variation you suggested and also make sure that I can reproduce the problem when using the Subsequent37 as a controller and that the behavior will happen on various MIDI OUT ports. I’ll use the Subsequent37’s arpeggiator. I’ll try to reproduce the problem using just the Pyramid’s pads as well, though the best way I can do that is probably to use the Delay effect and I don’t know what that will do.

If you have a Prophet 12, that makes me think that possibly you are the person whose very impressive YouTube performance videos convinced me to try out the Pyramid in the first place. If that is you I really admire the way of working you’ve developed.

34

I will test this out, hopefully this afternoon.

That could not have been me.
My music sucks and subsequently my workflow would impress no one. :wink:

(I don’t YouTube, either)

Edit to add what I’ve found so far:
P12 DIN MIDI OUT → Pyramid DIN MIDI Out A → Synth (Emu Orbit if it matters, it might since that’s the only synth or piece of hardware I have never been able to crash)

Using the P12 Arpeggiator and the [Hold] so I have hands free, I experienced a few dropped notes and a few “stuck” notes.

I recorded the MIDI Data into the Pyramid, saved the Project, then reviewed the *.mid file and the notes that ‘stuck’ still seemed to have Note Off Events which occured as the next Note On, which yielded instead of 1/8th note (I think that’s what that arp was pgmd for) a 6 step Note.

Pressing [Stop] once ended any ‘stuck’ notes, and it would seem at initial review that they weren’t stuck notes but that the notes extended up until that same note was pgmd to play. Hrmm

Interestingly enough, as I was setting this up I had it playing then started adjusting the Pattern Length I wanted to record into and that sent the data all wobbly wonk and insane. It’s a situation I used to run into in the ‘old days’ (read: 80s) when you sent too much data to a particular synth and in the case of specifically a Peavey ProFex if any data was coming down that MIDI cable whether it was destined for that device or not.

That was a strange one.

Here’s where it gets REAL interesting: So I just ran the P12 directly to the Orbit and still got the same results: a few dropped notes and a few stuck notes.

Not sure if this means anything, but i noticed that the ‘stuck’ (or rather, overly long notes) were the root note of the chord and the dropped notes tended to not be the root note, but I didn’t really pay close enough attention or figure out some test that would highlight that specifically.

So, in this case with the P12, the problem might be the P12. I’ll have to check if I’m running the latest firmware, but I know I’ve upgraded in the last year or so. I have an issue with the P12 USB MIDI randomly sending out Aftertouch data, but for now I just filter that out with my Event Processor. I’ve never checked with DIN MIDI because I’ve gained an appreciation for USB MIDI’s simplicity and speed.

PS: I just got a new toy delivered today, so it might take me a bit to test this, but I’m wondering if I can duplicate this behaviour with the USB. As it is, if your issue with the stuck notes is the same as the one I can duplicate (and it doesn’t even take a full minute…just seems that way because I’m listening to the same arp over and over and over…! LOL), then the problem seems to be the P12. If it is a ‘random MIDI centric issue’ (as in, relating to the nature of MIDI which is imprecise and I’m still amazed it ever worked in the first place), then the Pyramid might just be exacerbating an existing ‘nature of MIDI’ dramatic issue.

And there’s a bunch of those if you ask the old man.
And git offa mah lawn

1 Like
35

Thanks! I have more information to add as well. It is not conclusive yet, but thanks to your prompting I have an first guess of what may be going wrong now.

  • The problem does not happen at all with USB, only with MIDI OUT. With USB I cannot make the problem happen from the P12 and cannot make it happen by using Pyramid’s pads. It took a while to get to this observation clearly because the only thing I have that will route USB MIDI between the P12, Kodamo FM Essence, and Pyramid is the computer. To get this to work I had to set the MIDI channels on Ableton to route things the way we want for the test, set the monitor mode for the two MIDI channels to “IN” instead of “Auto” (not sure why this was needed, but it was), and run ThrottleStop, gamer overclocking software to allow the CPU to run a little hot without reducing its clock rate. Without doing all of those things, various malfunctions would happen on the computer side, spoiling the test and also resulting in dropped and stuck notes!

  • There is a chance that Ableton is cleaning up the event stream from the P12, which prevents Pyramid from seeing the “problem” note data, but this is not my first guess. See farther down.

  • Even if I torture Pyramid by stacking up several Delay MIDI effects (64ths, 128 reps) and sending notes from the P12 arpeggiator as 16th notes at 250BPM, the stuck notes problem is not reproduced over USB. The Pyramid does slow down and become a bit unresponsive, but that is not shocking. There is bug with the delay effect if you hit more than one different key before the delay repeats for another key finish, but that is not my current problem.

  • I know I said there was nothing special about the Kodamo that is making this problem happen. But actually there is something about Kodamo that makes stuck notes easy to observe. This synth has an unusually high maximum polyphony of 300 voices, so voice stealing is uncommon. The P12 only has 6 or 12 voices of polyphony, so a stuck note does not stay stuck very long if the synth is being overloaded. Therefore the arpeggiator test I’ve been doing might not cause a big problem if the synth were the P12 because even though the bug happens on the Pyramid side, voice stealing hides it. I guess the problem is probably easiest to observe with a synth that has lots of voices and with very short or 0 decay envelopes.

  • So, here’s one possible guess. Maybe there could be an overflow of outgoing MIDI events? The bug could be in DIN MIDI code or in the code that is common to DIN MIDI and USB MIDI. The first thing you think to do is to drop all MIDI messages that cannot be added to the output queue after it fills up. But this is actually wrong. The correct thing to do is to keep track of how many notes are in progress and start dropping NOTE_ON and CC messages, etc when there are fewer free slots in the queue than are required to send all the NOTE_OFF messages.

  • If that guess above is correct, how did I end up seeing this problem when other people may not have? Using MIDI DIN IN on Pyramid, sometimes using effects in a way that it could have momentarily overflowed MIDI OUT A? The thing is that I also saw this problem when I was just noodling around with no sequence playing. Never from playing one note in isolation though I think. So maybe the problem is not purely an output queue overflow. Maybe it is something like a race condition where at certain moments a lock cannot be acquired and so instead of outputting a MIDI message we drop it. If that is the case, there is a way to write an output queue that never has to lock on the read side (interrupt safe) but does lock on the write side, or vice-versa. Normally we can tolerate waiting for the serial port ISR to do its very simple job of loading up the output FIFO and updating the UART control registers.

  • And actually neither of the two above guesses make complete sense because what is really happening is that after the problem occurs the Pyramid internally always thinks the note is on. So a new NOTE_ON turns into NOTE_OFF, NOTE_ON and a new NOTE_OFF turns into nothing. So if instead of the race condition being for access to the driver it were for access to some other thing that keeps track of the note state, that makes sense. And without seeing the actual code there is no way to tell whether this is about not having a lock to protect the note state in some case or whether it is about having code that gives up if it cannot immediately acquire the lock. But anyway it starts to feel like this might be a bit closer to the mark.

Well, that is what I found out. I’ll also check more later. Since your idea about USB vs MIDI DIN has turned out to be fruitful, I’m guessing that I should be able to go back to MIDI DIN and reproduce the problem from the pads on the Pyramid now.

1 Like
36

Excellent - we’re moving forward.

  • Perhaps since the USB doesn’t do it means that it’s a throughput issue…? Reminds me of the old days. Also would describe why I haven’t noticed this issue since I’ve been USB MIDI from the Prophet
  • I’m wondering if since somewhere someone mentioned about putting a MIDI Thru inline and that it ‘cleans up’ the MIDI data or something something that it would be a good test. Will try that tomorrow.
  • In my tests, I took the Pyramid out of the formula: Only P12 → Synth and was able to replicate the behaviour. Might take a bit of time to reorg a few things since I don’t have a computer in the studio right now, but it might be a good idea to try to review this via MIDIOx which would not be in the business of fixing any Note Off failures.
  • There may very well be a stacking single note issue and that Ableton (when I viewed the *.mid file) ‘fixed’ on load that no Note Off Event was transmitted and/or it was swallowed. I don’t think the Orbit would have fixed that when it received the data, as I swear I used to do that stuff all the time when I was all experimental with the early days of the Orbit (and experienced this with a much older rig - mid-90s I think).
  • Overflow of MIDI Events is a good route to look at, but again: I could dupe it without sending any CC’s and just a raw Factory Preset P12 patch only playing the MIDI data on a single MIDI Channel with nothing else going on.

Exciting.
Maybe with this raw info some of y’all smrt people can make heads/tails and suggestions.
I’m happy to test whatever, but I don’t have the brain power.

OT: Kodamo - FM synth (drool) and 300 voices/16 part multi-timbral - plus can import DX7 SysEx, but it’s WAY more flexible than a DX7 (and looks easier to program!). I’m currently running Dexed samples through an Octatrack for my 80s FM nostalgia.

EDIT TO ADD:
Not sure if Pyramid is “fixing” the incoming Note Events data from the P12 and inserting a Note Off, but in viewing the *.mid file created on the Pyramid with Sonar (which allows an Event List), the longer notes are indicated at 1:045 which is 1 beat + 45 ticks whereas all the other Note Events are 15 ticks. Definitely needs review via MIDIOx, and I’m hoping that simple DIN to USB adapters don’t massage MIDI Events.

MIDI is so imprecise, but I’m still amazed it ever worked.
I wonder if this will be an issue with MIDI 2.0?

37

That is all excellent. I have not been able to make this problem happen when connecting the P12 directly to Kodamo, and I’ve tried. Putting Pyramid in the middle causes me to see dropped notes very easily and stuck notes with a little more patience.

Depending on the settings, I was causing Ableton to get stuck with errors also. The PC was only there in the test setup for USB though. In the DIN MIDI bug case I did not have Ableton.

You have a lot more experience with MIDI than I do, and I don’t have some of the basic tools. Is the best thing to get the biggest iConnectivity router/merger box, or should I be looking elsewhere? I haven’t read the MIDI 2.0 specs, though I downloaded them. My understanding, possibly incorrect, is that people have been talking about MIDI 2.0 for over 20 years. I’m not sure what the process was however. I like your idea of trying to reproduce this problem with fewer parts. Maybe I can use a software generator for MIDI messages and take the P12 out of the loop.

About Kodamo: I love this synth. It is so easy to program, and FM is so cool when it is easy. One of many nice things is that you can layer up to 128 voices per part, which makes the FM Essence a competent additive synth too. And at 300 voice polyphony you also are allowed to have 300 simultaneous different voices playing. This is only possible because of the layering, since there are only 16 MIDI channels (16 parts, or “patches”, each of which can layer up to 128 voices). Everything about Kodamo is so well done. It is so easy to program and I’ve made a ton of instrument sounds for it. I don’t know if it’s for everyone or not, but it’s my favorite thing.

Because of this experience I’ve just bought (but not yet recieved) a Yamaha TX81Z, Yamaha TX802, and Yamaha TG77. I wrote a small demonstration FM synth a few years ago and now I want the classic synths so I can port patches to Kodamo more accurately and maybe write simulations of them for more fun.

38

Now now - let’s not call something a ‘bug’ which we haven’t even been able to replicate to be able to determine if it is a ‘bug’. :wink:

I’m wondering if it’s necessary or helpful to try reproducing via USB in other types of connections. I don’t MIDIHub, but I have yet to try this setting up everything thru a USB Hub.

My understanding of MIDI 2.0 is there’s a lot more handshaking and devices setting terms between each other, which is super cool. But the backwards compatibility might get swept under the rug, or it might help out with issues like these.

Again: I can reproduce this without the Pyramid in the chain, which might mean that between you and I the issue might be the P12. With others it might be other devices, or the Pyramid itself, but I’m thinking this points to a generic issue with the nature of MIDI and it is in our best interests to instead of pointing a finger at who we think the culprit might be lately, to find a nifty workaround or solution. At least that’s where I’m finding myself heading.

Technobear tends to respond late mornings my time, so I wonder if he’ll chime in. He’s the smrt one. My experience gets chewed under layers of conceptualisations that only exist for a few on the spectrum (read: brain don’t work like commonfolk).

40

I can definitely replicate the problem, and when it happens I can observe the Pyramind’s behavior carefully and it is definitely buggy. We have already documented several concrete and repeatable ways to reproduce the problem starting over a week ago. The thing we’re doing now is adding some additional information about under what conditions the problem does not occur. This is not really necessary to have a good bug report. Usually one expects the software developers on the project to narrow things down once they have received a method of reliably reproducing the problem. And I supplied that from the start, but here it is again in its clearest and most updated form:

  1. Connect Pyramid to a power suppy which does not necessarily need to be a computer.

  2. Connect MIDI DIN IN to a Prophet 12, used as a controller. Connect MIDI DIN OUT A to a synthesizer. It is easier to test if you use a high-polyphony synthesizer but the problem it self does not depend on the synthesizer used. A high polyphony synth just creates a situation where you are likely to hear the stuck notes when they happen. Create or choose a synthesizer patch with max sustain level, minimum attack, decay and release time. This has no effect on the bug behavior, just makes it easy to hear when a note gets stuck.

  3. Send notes via the arpeggiator until the synthesizer gets stuck. To make things go quickly you can use 16th or 32nd notes and the 250BPM setting, but the high note rate is not the important thing. The problem happens randomly.

  4. Once you hear a note get stuck, stop the arpeggiator, open the Pyramid’s MIDI in monitor, and generate a NOTE_ON, NOTE_OFF sequence by pressing down the stuck key. If you’re using the P12 press the key smoothly and quickly because the P12 will send extra NOTE_OFF events otherwise. Likewise release the key smoothly and quickly. The stuck key should stay stuck and you can see the events com into the monitor.

  5. Now use Pyramid’s MIDI OUT monitor and repeat step 4 above. You will see NOTE_ON, NOTE_OFF sent when you press the key down and nothing sent when you release the key.

Here are my latest observations after re-testing yet again:

  • Once the Pyramid gets into its broken state, it always thinks a particular note is on, and when it sees another NOTE_ON for that bug it sends (NOTE_OFF, NOTE_ON) for that note. When it sees a subsequent NOTE_OFF for that note it sends nothing. There is no rational reason for the Pyramid to behave that way that I have been able to think of or anyone else has so-far. It is a bug.

  • I cannot directly reproduce the bug if I use the Subsequent37 as a controller in the normal case, but there is a special way that I can make it happen every time with the Subsequent37. While the arpeggiator runs, change the output MIDI channel. On the Subsequent37 this seems to result in mismatched MIDI events, and toggling through the output MIDI channel with the Subsequent37 produces several stuck notes every time.

  • Now it is a different question what exact sequence of MIDI messages on the DIN IN port make it likely that the bug will happen. I don’t think the P12 is sending extra NOTE_ON events or leaving out NOTE_OFF events for example, because if it were then I’d reproduce the problem with the Kodamo connected directly to the P12 and the arpeggiator on, and I cannot. But the P12 does seem to send long arpeggiator notes. The issue may have to do with MIDI message timing in some way? Alternatively there could be some electrical reason that MIDI events are sometimes lost between the P12 and Pyramid but not between the P12 and Kodamo.

  • To answer your question I don’t think it necessarily helps to try to reproduce the problem using USB now. I severely stressed the setup with everything connected via USB and could not reproduce the problem. Some interesting bad behavior did happen, but that is forgiveable given the stress test.

  • Here is one more interesting thing: The problem does not happen if I use the P12 arpeggiation output to USB for Pyramid’s MIDI_IN and Kodamo connected to DIN MIDI_OUT_A.

  • Right now we know this is a problem that only happens with MIDI DIN OUT. I really don’t think it depends on the controller but I can find out. It does not depend on the synthesizer.

MIDI 2.0 is an interesting thing, but since none of either of our devices support MIDI 2.0, including the Pyramid, it seems not to be relevant for the sake of understanding this bug.

Even though you can make a similar problem happen with a particular synth and without the Pyramid in the chain, it is not the same problem. That is because the problem I’m seeing does not depend at all on the connected synthesizer. It is entirely observable by only observing looking at the behavior of the Pyramid. It is helpful that the Kodamo lets me know the problem is happening audibly because it has high polyphony, but that’s not related to the bug that we’ve isolated to the Pyramid. I’ve seen a lot of bugs happen while testing–mostly Pyramid bugs but a few that are unrelated as well. We are trying to get more information about the stuck notes problem that really does come up in practice. We don’t care as much about the bugs that only come up when testing edge cases.

I think there are some things that are bugs that come up often in MIDI implementations but they are not necessarily problems with the MIDI specification per-se. The fact is that dealing with stateful, real-time note data is much more complicated in reality than you would think if you only read a description of the MIDI protocol. There is no way it can make sense for Pyramid to get into the mode I’ve observed. I can look at the input messages and output messages from the Pyramid’s MIDI monitor once it gets into its broken state, and it clear that at that point in time the Pyramid is getting good input and giving impossible, buggy output that we can’t justify regardless of the message history that we have not observed. The fact that we can make other things break in a similar way if we stress them does not excuse the Pyramid for having this bug. The bug comes up commonly for a number of us and does interfere with normal use of the sequencer.

Keith

41

there’s a lot to ‘unpack’ here…

I think we should start away from the assumption that there is a bug in what the pyramid is sending…
not because it may not be the case, but reading above… its is I believe colouring your analysis.
(ie. we are are trying to prove there is a bug, rather than determine if there is a bug)

some observations, from my side, partly as a developer… partly as a midi user.

these hanging notes are NOT happening with every synth over DIN, if they did this forum would be flooded with complaints… rather than a few users, with a specific setups.
also the pyramid has been around for years, so it would be a well known problem.
I know this doesn’t help YOUR situation, but it has to some how frame what’s going on.
why does it work for others and not you? what’s different?

from your description, your usage of the pyramid seems same as others - similarly its ok to other synths for you and via usb, so its something to do with hardware its being sent to, some ‘incompatibility’ between your synth and the pyramid… we just don’t know where/why.

I think you statement ‘it does not depend on synthesiser’ is basically false… I think its very much DIN OUT to the P12 thats the issue.
Im not saying, its 100% only the P12, we do not know how many synths it affects … just its not an issue will all (majority of ?) synths using DIN OUT.

USB midi works fine - ok, this is zero surprise to me.
the reason is DIN has many more bandwidth issues, and at the lowest level handled rather different.
e.g. DIN is strictly serial, whereas usb uses 4 byte packets for every message.

the ‘sequencer engine’ code on the Pyramid will send exactly the same message via USB or DIN.
so if message are missed via DIN and not USB, then this is at the transport layer not the engine.

MIDI DIN is very slow (compared to USB), too many messages WILL overrun receiving buffers on synths (how much buffer there is dependent on synths!) … that buffer is shared for ALL messages, clocks, notes, cc… any overrun will corrupt other messages but its true that missing note on/off are always the most noticeable… hence why transport issues are usually reported as hanging notes… probably other data is also corrupted BUT its just not so obvious.

re-writing midi…
yup, this is absolutely normal for almost anything with a microcontroller - so routers, computers, sequencers etc…
this is also done when your synth is doing ‘soft thru’
of course, the ‘thing’ will then re-write the midi message, not necessarily as it comes it, but rather as the developer interpreted the midi spec.

the main difference I see with this is in an area called ‘running state’. because midi din was so slow, there is are some optimisations which allow ‘repeated bytes’ to be omitted… particularly useful for CCs.
Ive seen devices that just don’t bother with this optimisations, even routers - I think just because we have more processing/memory resources so its felt less necessary. (and its completely irrelevant for USB)

how does this related to the problem at hand?

the issue is, its hard to say…
id say odds-on, the sequencer code for the pyramid is sending the right messages.
what I suspect is happening is either some hardware issue ( * ) over the DIN connection, or some timing issue.

this is not uncommon, I noticed a while back that my iConnectivity mioXM seem to fix some communication issues I had between a couple of midi devices (not pyramid related) .

I really don’t know if this was because the XM was re-writing the message, or has a larger send/receive buffer… its unfortunately impossible to know.
but from a user perspective, it was similar, both devices worked fine with other devices - just they didn’t like talking to each other :frowning:

(similarly I had an issue with my Virus, sending SysEx out that would baulk another device on the network, and had to use the XM to filter it)

This point also leads to another observation… which may be affecting why some users have more problems that others.

The pyramid allows for 64 tracks and a lot of complexity, so it is often used in larger setups.
however, the pyramid has very limited midi IO - no usb hosting, and 1 midi input and 2 midi outputs (and some cv)
SO, I think many pyramid users supplement the midi routing with various routers, splitters, mergers.
if you look over this forum, lots of topics / posts would support that assumption.

in my case, (and I think @CreepyPants ? ) , whilst I do often use the pyramid on its own directly connected to instruments (as a kind of portable setup) - id say 80% of the time its connected to a router.

how much impact does this have? we have no idea… but I do suspect some oddities with some instruments might be masked, because routers are being used.

I recognise its not a ‘solution’, but from a practical standpoint, Id recommend trying with a midi router - things like the iConnectivity, MidiHub , BomeBox - I think add so much extra value to the pyramid generally - and if they solve the odd issue like this , then thats a bonus :slight_smile:

(perhaps you can borrow one, or order from some where that allows returns to see if it helps - as there are no guarantees since I don’t have a P12)

( *) above some talked of the optocoupler, I did review that post, and Id urge some caution.
in that specific case, Squarp said it ‘seems’ like the optocoupler could possibly be the issue.
this was taken as ‘an acknowledged’ problem by Squarp.
my interpretation was more… given the details provided by the user, Squarp thought it was a possibility, but they have no way to verify it.

that being the case, that throws up questions like… was it a particular pyramid issue? if not, how many instruments does it affect? more questions than answers unfortunately?!

of course, if there were some oddities between two optocouplers , then sure a router/splitter would provide an intermediary that might fix the issue … though its not the only reason why a router might help.

1 Like