@Balwyn - excellent! that encapsulation really makes the switching a lot more stable. so far it's behaving much more robustly than my previous version. thanks very much!

hey folks! looking for some advice here. i have a custom instrument setup where i can switch between timbres based on a certain key range. there are eight ranges of four MIDI notes each and any one of these regions can be assigned to the base instrument, running on MIDI channel 1, or any one of five other instruments (running on channels 2-6). the switching method basically works as it's supposed to, but there are two strange behaviors

1. if i play quickly it can result in stuck notes as i switch between instruments. i have a method where i can send note off data to instruments via the interface, which mostly works to turn notes off, but not 100% of the time.

2. if i hold a note in one region down assigned to one instrument, and then quickly play another assigned to a different instrument, it will sometimes get confused and apply the sound from the first to the second. so if i have a piano timbre in the first region and play a key assigned to a synth timbre the piano will play notes in the second region as well for a time. i've found that if i play notes in a third different region it resets itself properly and the next time i play the second region it will be properly assigned. so in this case somehow the channel switching seems to be happening too late occasionally.

these bugs can sometimes result in interesting happy accidents, but as i work with it more (as well as playing faster or switching quickly between timbres) i want to have it be more consistent in response.

anyway here's my keyrouter object. the active region is set by the inlet. the output is rearranged to put the channel first so i can route it to the correct instrument. there's probably some kind of race condition that behaves properly when the region and timbre switching is clean (playing more staccato or detached) but if notes are held down or the speed of switching increases it starts dropping noteoffs. any input or info appreciated!

keyrouterTest.pd

thanks very much - will give this a try!

hi folks! i'm working with my patch and noticing that even when idle the CPU is 30% or so. this is with DSP on of course. otherwise it drops to about 5-6%.

after some sleuthing i found that the culprit appears to be my synth bank and fluidplayer objects, so i'd like to implement a switch~ object to shut off their outputs which are stereo but i don't want to manually control it. i'd more prefer a sort of timed noise gate where it waits something like 3 seconds once the sound has reduced past a nearly silent threshold, and then ramps the signal down and shuts off the DSP.

anyone have some examples of this kind of thing?

additionally, i have experienced a substantial DSP spike of over 100% that unfortunately i cannot reproduce at the moment. i am running Jack with a very small buffer because this is a live performing instrument and i need instant, or near instant response from it.

advice or examples appreciated!

hey folks! i've recently run into a situation in which i have to recompile an external currently only available for mac ("pd_darwin") to a Windows platform. the code was ported from the original C/C++ code of the Mutable Instrument module called Plaits. basically it's just a release of the DSP code as a PD object. it's hosted here:

https://github.com/jnonis/pd-plaits

he's including the xcode project but i believe the code itself is just straight .cpp files wrapped into the PD external template code. i think he's using the pdlibbuilder library that's been recently released, but i have had absolutely zero experience with compiling the source for different platforms. the meager amount i know is you use a command line and probably the Makefile but i know some of you have done this, and so i'm wondering what one should do to compile this for a Windows build. shoutout to @porres for some help (since you did the ELSE libraries) do i need to use/install MinGW? i have a macOS and Windows 10 machine, but if i recall it's not necessary to have a Windows box to compile a DLL for that platform. anyway, any help appreciated!

@mianmogra thanks very much! i was a bit confused with some of your other mkmr instruments but this object had just enough information for me to unpack one of the [mymembrane~] objects and see how you put it together. i started doing some modifications to the patch and i'm happy to say i'm making good progress! interesting that allpass filters are so useful.

i'm not great at DSP theory but i've been wanting to adapt a Karplus-based instrument to get something more interesting and expressive, and this finally cracked the door open a bit.

what i'm really interested in is creating a close approximation of a piano string that i can then mess around with to get more timbres similar to prepared piano. i was impressed with your [piano~] patch as a completely synthesized representation (even if it's a little cheezy sounding) but i couldn't figure out how it worked to modify it. i'd like to ask you more questions on this in the future if you're available. thanks!

@Nobody it's actually pretty easy. if you go to his github link he posted you'll see a pd-mkmr link listed near the top. click on that link for the main repo page, and there's a green button on the far right corner that says 'Clone or Download'. click that to get a zip of the repo. unzip that file and inside are all the patches from the whole mkmr collection and it should be under the Instruments directory. hope this helps!

this is great! i downloaded your mkmr abstractions earlier, but i think you really are getting to very nice places with this - especially the snare drum sound is pretty convincing.

i would be really interested in getting your advice on some of your other instrument patches like [mct~] and the [piano~] patch. i would really like to know how to extend the basic karplus setup so that it could work for modelling a piano string, but i want to also be able to change the timbre in a variety of ways. your instrument patches really sound great, but i would love to know what to tweak in order to make them sound more unusual and experimental. can i message you here with some questions on this?

@whale-av - thanks David! that is pretty much indeed what would work for me. oddly enough i play with only one speaker so most of my samples are actually mono, so i don't need it to load stereo sounds into two separate buffers. i did notice the sample start end issue while looping. if i set the end point for the absolute end of the sample i get clicking and the sample doesn't repeat/loop. i was able to solve the issue by moving the end point in from the edge a very small amount and then it behaved fine. i don't currently require the total loop length to the last sample, and may never need to worry about it really.

the only other issue was that the loop region couldn't be set to a really small size. i got pretty close by changing the [metro] timing rate to 10 from 100, though. honestly this is just about everything i need to move forward, so thanks immensely!

scott

thanks to both of you for your reply! @seb-harmonik.ar - i'll check out your approach, as loop~ was getting pretty close to the behavior i wanted in the first place and i couldn't figure out how to get reverse playback.

@porres, actually i would be completely satisfied with current behavior in [player~]. just add the ability to create a loop size without resizing the buffer. this is pretty much what the [groove~] object does in MaxMSP - look at the attributes section:
https://docs.cycling74.com/max5/refpages/msp-ref/groove~.html

the [wave~] object in MaxMSP to my recollection is a bit of a different beast, as it's limited to a very small amount of samples (or it used to be anyway) and is intended for wavetable synthesis, not sample playback from a buffer per se. however looks like the current version in Max removed that sample length limitation though, and works in a similar manner. biggest limitation i can see about it though, is possibly no ability to change pitch, or do reverse playback, both requirements for me. i might be wrong but i don't clearly see those options.

let me check cyclone's [wave~] object reference...okay it looks like variable speed playback and reverse is supported and there's no sample length limitation. but resizing loop length really messes around with the sample playback rate and i'd prefer it not change pitch/rate while that happens.

i think i would put a request in for a feature change add for [player~], as i think it would be helpful to others to have at least one object that could have adjustable loop size as well as directional varispeed.

cool! thanks for the clarification. it was a bit confusing.

so i tried the moop~ external and its interesting! it looks quite versatile. i tried it with a 15 sec sample and playing around with the presets i found that about 2/3 or them would produce sound i could hear. i'm obviously inexperienced so i could have easily done something to encourage wonky behavior.

anyway, despite that, enough of the settings worked that i could see its capability. it looks like it does forward/reverse and the pitch change via the [mtof] object and there's a lot of ability to chain together sequences of buffer positions for a complex effect (although it seemed like most of them were non looping).

but the pitch change offered by the (fake i think?) [times $1 pluto] isn't quite what i want in terms of varispeed. i need a more traditional speed control, more like a DJ scratch or pitchwheel scratch but with a variable loop size. is it possible you could give me some tips on getting that into the help patch of moop~? i'm assuming i need something like a [line] or manually driven [phasor~]. i'm pretty inexperienced at this digital signal theory. for example, it's weird how you can drive either input of [sig~],[*~], etc in order to get pitch change. still wrapping my around that...

hey folks, i'm sure this can't be a new issue but i'm using PD 0.49 using the [loop~] object (it's in the else library as well as ceammc] and i'm on the warpath to create a variant to **[loop~-help.pd] **that allows reverse, and maybe improve the looping performance so it clicks a bit less. here's a screen:

i've also been looking at the ELSE library from @porres. there's a lot of objects there that could work, but i need to be able to change loop size and the help file for these doesn't seem to indicate that any of the objects can do this - it seemingly loops the whole length.

any assistance on either of these issues would be helpful - thanks!

ooh interesting! i though i'd have to use [pack] or something, but forgot that message boxes can contain multiple items. most excellent - will update the patch accordingly. thanks!

hey folks - greetings to the board!

i'm in the middle of designing a pretty simple sample playback and recording setup and i've consistently run into some issues that i seem to only be able to solve by using [del] which i know is generally discouraged. but it doesn't seem to work properly in the accepted way using a trigger. here's an example where i get the size of an array:

[array size]
|
[set $1(
|
[t a b]
|   /
| ___ (

so, what happens in this case is when i bang the [array size] object, the blank message box at the very bottom is updated (it's connected to a send object which i did not draw) but its value is not sent by the bang coming from the trigger object. if instead i insert a [del 25] object after the bang outlet everything works properly. i'm pretty sure i'm likely not doing something right but to me it looks like the bang happens too fast and doesn't have time to send the message out, but i've seen this behavior when reading from [openpanel] too, and when switching between arrays. see the pic below.

can anyone shed some light on this situation? it seems like [trigger] should work but it's consistently late.

thanks in advance!