• Load074

    OK... one crash-during-performance later, I'm looking more closely into this.

    If I have the USB device set to "Output Device" as well as "Input Device," and unplug it while PD is running, PD will crash. If, however, the device is only "Input Device" and not an "Output Device," unplugging it is no problem.

    Also, if I have PD set to "MIDI Through-Port [0,1,2,3...]" (instead of looking directly to the device) and make the nanoKONTROL2 -> MIDI Through-Port in, ie, qjackctl, then I can unplug without a crash.

    So! Maybe I should file a bug report? Or maybe someone else who has an input + output USB MIDI device and is running PD on Linux (or, who knows? any platform?) wants to try this out and see if it's just me?

    posted in technical issues read more
  • Load074

    Hear, hear. I've been getting into the habit of (trying to) ALWAYS use [t whatever whatever], even when it seem unimportant. Too many times have I been bitten by a seemingly-innocent execution order (egad that sounds sinister) from the earliest experimental stages of whatever patch I've been building.

    posted in technical issues read more
  • Load074

    @oid thanks for checking your system. It's probably an Arch-thing or, more likely, a me-thing then.

    I haven't changed anything about my setup, and I've used this Arch & PD installation for at least two years now. I use Jack for audio and MIDI, and usually use PD itself to make the connections (although to be honest - and this is a question I've had for ages now - I'm confused about PD MIDI connections / ALSA MIDI / Jack MIDI, and how sometimes I can make all choices in PD, and sometimes (depending on the PD version?) I have to use Jack).Screenshot_2024-01-28_10-51-57.png

    posted in technical issues read more
  • Load074

    This is new, I believe. At least, I've never encountered it before, and I'm sure I've hot-swapped in the past.

    So: in PD 0.54.1, if I unplug the USB MIDI device (ie, tested both Korg nanoKontrol2 and nanoPad2), PD just up and quits. I don't need to be monitoring anything (like with [ctlin]) though the device needs to be one of my input/output devices.

    I'm running up-to-date Arch Linux, kernel 6.7.1. Anyone else? Just me? Bug report, or is there a bug in my brain?

    posted in technical issues read more
  • Load074

    @beep-beep Hot dog - your comment actually pointed me towards something that works good enough for me!
    Using [abs] will at least keep everything positive, so the discontinuities aren't crossing the zero line... and then, to make it even prettier, I inverted it with [* -1] to make a mirror image.
    Since this is just for looks, I think it'll be good enough... it may turn out that I need a smaller viewer (less than 2000 points) even still, but so far, no glitches, and it looks reasonably like the 7-minute file I loaded.
    Screenshot_2024-01-23_21-42-53.png /home/scuttlebutt/Pictures/Screenshot_2024-01-23_21-42-53.png

    posted in technical issues read more
  • Load074

    Thanks - it's good to know, at least, that it isn't just a simple obvious object I was overlooking. And thanks, @nau, I'll take a look at those libraries when I get home!

    posted in technical issues read more
  • Load074

    It's SO satisfying to have a little [hslider] moving along under an [array] which shows the waveform... maybe you can even grab the [hslider] and drag it to a new point in the file/sample...

    But they're SO BIG! Any long sample is made of of many points, even if the display is shrunk down. That makes my PD hiccup whenever it needs to redraw the waveform (ie, minimize then maximize the window).

    I've tried making a duplicate of the real [array], but forcing it to be "lower resolution" (say, 1000 points). Sadly, sampling every "arraySize / 1000" points and writing that to the arrayView doesn't look anything like the original. Neither does averaging all the samples within a given chunk... though it DOES take a long time!

    Is there another, easier, more commonplace solution I'm overlooking?
    image.png

    posted in technical issues read more
  • Load074

    wait wait wait... are you telling me I don't have to use [this( and [next( !?!?! How else does one do it? Oh... can I keep a counter in my main patch, and send messages to successive [clone] 's? So then I'd know I was on #47, and I'd send all my details to #47... is that how that works?

    Brilliant.

    Hold on, I'll be back in a few hours....

    posted in technical issues read more
  • Load074

    not to get all High School Yearbook, but... "sorry so sloppy."

    The cloned part is "changeGrain." My front-end patch has four of the "quadSamp," each one of them relating to a specific sample. They get triggered quickly (as fast as 5 ms), so there can be a time where four different samples are triggered within 5ms of each other.

    quadSamp is also where I can set, ie, the rate or the filter to be different for Sample A than for Sample B.
    quadSamp:
    Screenshot_2022-02-01_06-52-55.png
    quadSamp.pd

    And so the problem is that, for instance, Sample A is Duran Duran's "Fame" but filtered and slowed down - no problem - but when I occasionally trigger Sample B (David Bowie's "Fame") I hear bits of Sample A at normal speed and unfiltered (following Bowie's parameters).

    changeGrain (that which is cloned):
    Screenshot_2024-01-05_17-29-59.png
    changeGrain~.pd
    This might not make sense, and my patches might be too personal/messy for anyone to want to take a look...

    posted in technical issues read more
  • Load074

    Trying to fully fathom [clone]...

    I am working on a granulator patch which uses many [clone]s, and four possible samples to choose from/mix between (ie, 25% chance of grain A, 75% chance of grain B ). I think Carl Stone might already do something like this, but he uses Max, so, totally different.

    Anyway. I'm using a [t b b b b...] to, first, a [next newName $1( to choose the sample, then a bunch of [this rate $1(, where the "THIS" messages are attributes (rate, filter, whatever).

    When I'm mixing my grains (ie, anything other than 100% of grain A), the "THIS" attributes sometimes get applied to the wrong sample. That is, if I know grain A should be slow and heavily filtered, and grain B is fast and bright, I hear some A's fast and bright.

    I thought using a [t b b b b] would ensure that the the same sample chosen by [next( would receive all of the appropriate [this( but... no?

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!