Question About Super Poly Mode - Bugs?

[Futureman]

I'm not sure if these are known bugs, and I'm aware that Super Poly is still in the semi experimental stage... so please bear with me if I'm stating the obvious.

If I set up 3 Sids, All to super poly 3, All to midi channel 1, often that works fine, like a 3 voice poly synth.

If I want to get some crazy voice rotating thing going on like, SID 1- Patch A, SID 2 - Patch B, SID 3 - Patch C, Often when I change one Sid's patch, the voice rotation seems to have a hole in it, or a double up..

ie, If I press three notes in a row.

SID 1 ->  (SID 2 & SID 3) ->  HOLE

           

Where it should be something like this

SID 1 -> SID2 ->  SID 3

If I save the Ensemble, and then get back to it, everything is fine.

It almost seems like the flag to what SID gets played when gets mixed up..

Another weird bug is if I select say 3 Sids, switch em to super poly, switch em all to midi channel 1, then we are running like a 3 voice poly synth..

I've noticed that sometimes, when I change the patch (ie, all three SIDS at the same time) sometimes, 1 of the patches sounds different, ie at a different tuning, or filter setting.

This seems to happen more often if there is note info going on at the time (Well, it seems that way)

Sometimes, I can go back to those patches for all 3 SIDS, and the tuning problem is gone.

I need to play with the above bugs to see exactly when this pops up, so if I find anything out, I'll post it ASAP.

Much regards

[Wilba]

Super Poly mode works by setting up each synth engine to skip playing notes (i.e. ignore the Note On events). So for example if you setup SPV=4, then Core #1 will handle the 1st Note On, then ignore the 2nd, 3rd and 4th; Core #2 will ignore the 1st, handle the 2nd, then ignore the 3rd and 4th, etc.

Changing patch on only one synth engine (i.e. Core) will reset the "note stack" and so that engine will be out of sync with this distribution.

(This is how I think it works or used to work - TK may have changed it)

It's probably best to dedicate one Ensemble for Super Poly mode only, with all engines set to the same Lead patch, and then change the patch on all engines simultaneously. If you want to do funky stuff like changing the patch on only one engine, for now, you can work around the problem you're experiencing by resetting the other engines by switching to a different patch and then back to the patch they were on - this should reset the note stack.

[TK.]

I already fixed these bugs, the new code is in the repository (see comments in the logs) and will be released very soon.

However, there are still situations where the SIDs can go out of sync, e.g. if a huge bulk of SysEx data is received in parallel to MIDI notes (a MIDI IN buffer overrun will happen). A different, more complicated concept is required to solve this failsave (centralised voice assignments handled via CAN). I'm not sure if I will implement this for the PIC based solution, or if it will be only available for a future STM32 based solution (where I'm planning a Super-Duper-Poly Mode with 8 individual voices :))

Best Regards, Thorsten.

[Futureman]

Sweet! I look forward to SDPM!

Thanks for your prompt replies.

Regards

Mike

[Wilba]

Super-Duper-Poly Mode sounds cheesy. Can you call it "Ãœber-Poly Mode"?

("Ü" supplied by nILS, thanks!)

[Labelwhore]

Super-Duper-Poly Mode sounds cheesy. Can you call it "Ãœber-Poly Mode"?

("Ü" supplied by nILS, thanks!)

I second the notion of calling it "Ãœber-Poly Mode"

[TK.]

It's my intention to give the new mode a cheesy name!

For the case that you haven't noticed it yet: the name "Super-Poly" was already a joke...

You can call it SDP mode if you don't like this kind of humor ;)

Best Regards, Thorsten.

[Futureman]

Hey there.. I uploaded the newer 6582 OS located in "midibox_sid_v2_rc26" and played with super poly mode a bit.

I noticed that the same bug is there when change just one voice etc.. sometimes the "stack" gets out of sync and this problem

SID 1 ->  (SID 2 & SID 3) -> SID 4 -> HOLE

Can still exist.

I'm not sending the synth anything fancy other than keyboard info, and I'm not even pressing keys while changing just one patch.

I do realise that this can be avoided by saving the multi patch, and then returning to it, but I honestly think that it's cool quirky tricks like this that make a synth memorable (There a heaps of normal bland vanila synths out there that play just like a normal poly)

A couple of times, even when changing all patches at once (All 4 Sid voices selected) the above bug still happened.

I looked at the 6582 file, and it was modified on 22/12/08, so I thought that maybe it had been fixed up? Could this have been overlooked?

Sorry to be a pain, I would honestly fix it up if I knew how.

Regards

Mike

[TK.]

Did you update the firmware for all slaves?

Once this firmware is booting, and the version number is displayed, 
press&hold the MENU button of your Control Surface to "clone" the new firmware 
to the slaves via CAN interface.[/code]
Does it always happen for SID2 and SID3 only?
How does it behave if you swap the PIC of SID2 with the PIC of SID4?
Best Regards, Thorsten.

[Futureman]

Hey TK.

I did update the firmware on all PICs (While holding down the menu button)

I also verified the update with an firmware upload of the test tone app..

My example about the hole in the voice rotation was not that specific, sorry for the confusion, but It's hard to know which voices are getting missed / moved around / doubling up etc.. sometimes when I change an individual patch of a SID voice (While in Super Poly Mode) it will work fine, but sometimes it won't and I'll get a hole.

Do you still want me to swap the Pics around?

Do you think this is specific to my Sid Synth?

Regards

Mike

[m00dawg]

I'm not sure if I will implement this for the PIC based solution, or if it will be only available for a future STM32 based solution (where I'm planning a Super-Duper-Poly Mode with 8 individual voices :))

Woo! Moving to an ARM platform? That sounds exciting! I assume with that much power you could consolidate all those PICs into one single controller?

Also, I'm not sure how far along you may be, but have you looked into the Parallax Propeller stuff? It's 32-bit, RISC-based, and has a multi-core "Cog" system. You can dedicate one or more Cogs to a specific task (such as controlling a SID, handling the control-surface, etc.). It's also quite fast from what I understand, though I forget the MIPS rating specifically. Some guys at my local hardware meet-up have used it and have said some really good things about it, although I haven't had an excuse to use one myself yet.

[seppoman]

Woo! Moving to an ARM platform? That sounds exciting! I assume with that much power you could consolidate all those PICs into one single controller?

Also, I'm not sure how far along you may be [...]

Good morning m00dawg  ;)

http://www.ucapps.de/mbhp_core_stm32.html

There's also a lot of stuff already done for Seq V4 on STM32, bootloader, MIOS32 etc, so I guess you're a bit late for suggesting other controllers :)

S

[m00dawg]

Hahah wow yeah it looks like it's almost done :) Probably just as well. ARM is likely more powerful than the Propeller stuff and having an a mature platform that works with GNU Tools is a pretty big deal. According to the link, it seems like it won't be that much more expensive either, which is nice! Only thing that I don't like is the SMD stuff. I jones for sockets :)

Looks really promising though! You can bet I'll be grabbing one of these up once they are on SmashTV's shop!

[Futureman]

... Back on topic...

I played a lot more with SPM to see if I could find out when the bug happens.. placing 4 distinct voices (Saw / Square / Cymbal / Kick) in the ensemble and saving that.

When returning to the ensemble, and then individually changing voices, the "hole" and double up in the voice rotation seemed pretty unpredictable..

sometime it was

Hole - (1 + 2) - 3 - 4

1 - 2 - (3 + 4) - hole

1 - (2 + 3) - 4 - hole

etc...

Sometimes it was fine 1-2-3-4

I also noticed that while all 4 voices are selected & have the same patch etc, any change to the matrix routing is not duplicated in the other 3 voices ( 2 , 3 & 4 ) while other changes to the voices such as filter / osc controls seem to be all duplicated.

This seems pretty fundamental to a poly synth working properly..  I find it pretty hard to believe that I'm the only person who has come across this bug? Am I missing something?

As always, thanks for your input/help TK.. I know that I sure as hell would not be able to fix this on my own

Regards

Mike

[TK.]

I also noticed that while all 4 voices are selected & have the same patch etc, any change to the matrix routing is not duplicated in the other 3 voices ( 2 , 3 & 4 ) while other changes to the voices such as filter / osc controls seem to be all duplicated.

confirmed (although I don't know, why it isn't working as intented anymore - it worked in earlier versions)

When returning to the ensemble, and then individually changing voices, the "hole" and double up in the voice rotation seemed pretty unpredictable..

confirmed - it happens due to a MIDI In buffer overrun at the slave side while a patch is transfered via CAN.

I cannot provide a fix for such issues under PIC based MIOS. The whole RAM is allocated, no place to enlarge the MIDI In buffer (64 bytes can only bridge 20 mS)

We've two solutions: either I provide a workaround (Re-init voice allocation after a patch change on any SID, or by pushing a special button), or I have to cancel this experimental feature, as it doesn't work under all conditions and leads to a lot of support effort at my side. I already spent too much time to fix issues here and there although I knew that it's only a tinkering solution to try out, how 4 stereo SIDs would sound while they are played poly.

I will be more careful in future before publishing such experiments.

It will definitely work properly with a MIOS32 based solutions, as FreeRTOS provides such nice features like preemptive multitasking and Mutex for a proper synchronisation between tasks.

Best Regards, Thorsten.

[Futureman]

Please don't cancel Super Poly mode...  :o  I've nearly just about finished building my massive Sid synth all because of this mode!!!!!!

If you can re-init the voice allocation after any patch is changed, that would be super!

I do realise that this is taking a fair amount of time to fix, and I really appreciate your help..

Kind regards

Mike

[rutgerv]

Hi TK,

as you know we also had some discussion about this and I can confirm what Futureman reported: the latest update doesn't solve the problem (although it occurs less frequent!).

I understand that you have spent quite alot of time (way more than intended) to get this experimental feature working and don't want to work much more on it for the PIC based version. However, I think people are just starting to discover the power of the SIDV2 and quite alot of people own (or are constructing) a version of the SIDV2 that really benefits from this SPM feature. Partly thanks to Wilba I guess :). I myself and probably everyone using Wilba's design, have the entire synth on a single PCB, which makes it hard (and ugly) to make modifications. To be honest, I personally would not upgrade to ARM for this reason.

I would propose to overwork the SPM to make it work properly for the PIC based version. Centralizing the control of voices sounds like the best plan, while using the CAN bus to switch the voices on and off (if technically possible). I would also propose to simplify the mode quite a bit to make it only use 'all available voices'. I really think there's no need for variable assignment of voices to the SPM, since the number of voices is too small anyway to use it multitimbral. From my point of view the biggest novelty of this SPM is the fact that you can play polyphonic (with the same number of voices as a Jupiter 4) on SID sounds and the fact that you can do this in TRUE STEREO! For instance, the string sound in the demo I put on the forum, is using 4 voices in true stereo. Together with the character of the SID, this sounds unique! As far as I know, there's no other analog synth that has true stereo oscillators! I took a little time to discover the power, but if I now have to choose between 8-voice mono or 4-voice stereo I would defintely choose the latter!

Best,

Rutger

ps. By no means I'm trying to put pressure on you. I'm just hoping to make you enthousiastic about what I feel is right for the SID V2. I'm willing to help in any way I can (discussion of the concept, debugging, building patches), if you decide to overwork the SPM.

pps. I have a very nice set of polyphonic patches (string sounds, pads, etc) which I just might share..... :P

[stryd_one]

I will be more careful in future before publishing such experiments.

I don't know about the other guys, but I'd rather be a lab rat for your experimental software, than miss out altogether - even if the experiment fails. IMO: Don't be careful, just mark it as "unsupported feature" or something ;)

[rutgerv]

I don't know about the other guys, but I'd rather be a lab rat for your experimental software, than miss out altogether - even if the experiment fails. IMO: Don't be careful, just mark it as "unsupported feature" or something ;)

[TK.]

Ok, you asked for the changes:

RC27:
  o Super Poly voice queue now handled centrally from master.
    Slaves notes are triggered via MBNet
  o SPV value now changed simultaneously for all slaves
    It can only be changed if master SID selected
  o PLAY button now plays a chord in superpoly mode
  o Mod matrix changes forwarded to all selected SIDs
[/code]
Don't forget to update the firmware on the slave cores as well!
Please note: while we previously had an asynchronous voice handling with the risk for inconsistencies, we now have a central voice handling with the risk that the master has to wait too long for a slave (depending on the SID engine load), so that a MIDI IN buffer overflow could happen. The PIC just hasn't enough memory for preemptive multitasking, which would easily solve such issues...
However, so long the master doesn't receive MIDI Notes back-to-back over a period of more than ca. 20 mS, it should work properly.
If you notice hanging notes, press the PLAY button to reset the voice queue.
Now I would like to see a full bank of new patches provided by users! :)
Best Regards, Thorsten.

[Smithy]

TK after reading your replies and also the STM32 page,

I would just like to point out once again that your accomplisments never cease to amaze and inspire me, and so many others....

by how you keep pushing the metaphorical "envelope",

Constantly adding what seems like an infinite range to its "decay" and "sustain" level...

by having such a clinical,  dedicated and optimal work ethic,

Kicking the MIDIbox concept further into the future than i can ever imagine.

It is this amazingly kind,selfless and passionate  attitude that makes me realise how beautiful a thing humanity is, and can be.

And this is also dedicated to all the other key MIDIBox players who work their asses off, to help this community reach its full potential.

Observing this sense of community spirit has warmed my heart  many times, and i just felt like expressing my gratitude to help make ye more  aware of the positive impact ye have on peoples lifes  and their music.

BTW - I'm completely sober writing this,  (maybe hard to believe due to my nationality ;) ) drugs inclusive

i'm  just high on that MIDIbox Love.  :)

[rutgerv]

Oh my god! TK, you're amazing!

I'll will get you this bank of polypatches ASAP!

Rutger

[rutgerv]

Hi!

I've been testing the changes today and it really works well! The voice handling runs really smooth. However a minor new problem occured: polling of the slaves sometimes failes when using the editor with WOPT parameters (meaning that the CAN bus is busy for a while and not having spare bandwidth to reply to polls from the master core). Maybe the polling time-out could be increased a bit?

Best,

Rutger

[Futureman]

Brilliant! SPM working tops! A++ for you TK!

Regards

Mike