jasperspeicher

Hi. This will start off sounding like M4L problem, but I believe the issue runs deeper than M4L.

There is a patch called "Bassline" that comes with M4L. I started using it. Its polyphony seemed to be broken, as turning up the polyphony setting seemed to make no difference, and cranking the release value on the synth params caused subsequent notes to be dropped. Furthermore, the problem seemed to get worse the longer I left a live session open, and the only solution was to turn the release down and reload the instrument periodically.

I decided to do some detective work, so I put lots of print statements in, hard coded the poly to 16 voices, and looked at the output. Whether I run it as a m4l device, or as a standalone patch, the same issue seems to persist--the automated voice selection seems not to be working. The MIDI notes are making it to the poly instances, but they are not making sound.

Check out the max window output for these two subsequent MIDI notes. The first note makes a sound, but the next (which is played while the first one is still sounding its release) does not make a sound.

---------------------------------------------------------------------------

instance_midi_note: 1 78 100 //numbers are: [voice reported by thispoly] [note value] [velocity value]

mute: 1 0 //numbers are: [voice reported by thispoly] [thispoly mute state]

busystate: 1 1 //numbers are: [voice reported by thispoly] [busy state sent to thispoly]

instance_midi_note: 1 78 0 //*** this looks wrong. why is voice 1 getting a note when it is busy?

I am not sure what is going on here, but I am including a link to the patches below. You will need some m4l objects to run it.

http://www.mingar.com/jasper/externallyLinked/patchingTests.zip

Hi. This will start off sounding like  M4L problem, but I believe the issue runs deeper than M4L.

midinote_to_poly: midinote 78 100
instance_midi_note: 1 78 100            //numbers are: [voice reported by thispoly]  [note value]  [velocity value]
mute: 1 0                                                //numbers are: [voice reported by thispoly]  [thispoly mute state]
mute: 1 0
busystate: 1 1                                        //numbers are: [voice reported by thispoly]  [busy state sent to thispoly]
midinote_to_poly: midinote 78 0
instance_midi_note: 1 78 0                 //*** this looks wrong. why is voice 1 getting a note when it is busy?
midinote_to_poly: midinote 79 100
instance_midi_note: 1 79 100
mute: 2 0
mute: 2 0
busystate: 2 1
mute: 1 1
mute: 1 1
busystate: 1 0
midinote_to_poly: midinote 79 0
instance_midi_note: 1 79 0
mute: 2 1
mute: 2 1
busystate: 2 0

poly-in-c74-patch-in-m4l-broken

Well, replacing the poly's patch with the patch pasted inline below this message fixed the problem. The control info for the synth appeared not to be getting to the instances the way that C74 had it. I just put in a receive object that skips the poly's control inlet all together.

One thing to note--the way they handle polyphony in the device is not ever going to give you more than 4 voices, regardless of the number you set. If you want 16, for example, you have to set the poly arg to 16. Then, if you decide you want the behavior of 4 note polyphony, you can set the box to 4, and it will exclude voices 5 through 16. I am guessing this is because they were concerned that adding and removing instances at runtime might crash live?

I am posting an updated version of the entire device to the link below. Note that it is set to 16, because 32 is using way too much cpu for me. I have also set the max value of the polyphony number box to 16 so that I do not go crazy later on.

http://www.mingar.com/jasper/externallyLinked/Bassline_jjs.zip

Poly~ in C74 Patch in M4L Broken?