• metaphysician

    @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!

    posted in output~ read more
  • metaphysician

    @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!

    posted in output~ read more
  • metaphysician

    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?

    posted in output~ read more
  • metaphysician

    @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

    posted in technical issues read more
  • metaphysician

    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.

    posted in technical issues read more
  • metaphysician

    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...

    posted in technical issues read more
  • metaphysician

    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:
    Screen Shot 2019-04-06 at 7.01.01 PM.png

    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!

    posted in technical issues read more
  • metaphysician

    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!

    posted in technical issues read more
  • metaphysician

    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.

    Screen Shot 2019-04-06 at 3.01.19 AM.png

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

    thanks in advance!

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!