thanks johannes, good advice. i replaced the notein with a makenote (and your random select chain) and set the metro duration one below the note duration (to get overlapping notes) i can go down to 5ms notes and it does not glitch. i also changed the fanouts to triggers as suggested and changed the reset of the glide. find patch attached.
i will try this patch tomorrow with my midi controller and see if it glitches again. what puzzles me is that the glitching only occurs with the glide portion in the patch. without it, it is fine with my controller. this led me to believe that it had to be an issue with the counter, rather than the midi input. could the pd/os bridge also be an issue e.g. the midi implementation? basically my controller sends note offs immediately (as fast as midi allows) after the new note on. maybe that is somehow too fast? also note that my controller has a direct usb-midi output, no need for an extra midi-usb device. maybe data arrives faster at the usb port then via serial midi? some shots in the dark. cheers
legatoportamentomidibass2.pd
Description: Binary data
> On 27 Jun 2017, at 21:09, IOhannes m zmölnig <[email protected]> wrote: > > On 06/27/2017 09:03 PM, Simon Iten wrote: >> it works fine here as well as long as I don't send very fast runs (20 notes >> per second and more) did you try with fast midi input? > > for testing, try to get rid of any hardware device, and replace it by a > stub (e.g. [metro]+[random 4]+[select 0 1 2 3]+[64 100(...) > > as a general rule, though shalt also get rid of *all* fan outs and > replace them with triggers. > > gfmdsa > IOhannes > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
