• jameslo

    Probably no longer relevant, but I found a way to not have to double the buffer size.
    circularBuffer2~.pd
    circularBuffer2~-help.pd
    Screenshot 2023-01-31 104318.png
    Edit: Oh I see now (too late) that [list store] might be better to use than the get-prepend-set way that I'm reordering the buffer https://forum.pdpatchrepo.info/topic/13643/is-there-a-maximum-list-length-or-message-size

    posted in technical issues read more
  • jameslo

    Just curious: say your new BPM is off by 0.001 and around 120. I think 0.001 is a lot bigger than anything you've been discussing, but I could be wrong. Anyway, doesn't that mean that over 10 minutes, your beat will be off by 1/100ths of a quarter note, and the pitch will have been off by less than 2/100ths of a cent? (I'm glad they didn't demand that kind of precision when I was in music school!)

    posted in technical issues read more
  • jameslo

    @lead Sorry, still not quite understanding what you're after. Is the 77 BPM example bad because it has 4 decimal places instead of 3 like your good examples? Or are you asking "which BPMs when pitched down 2 semitones results in a BPM that has as few decimal places as possible?" It would be cool if you were asking https://math.stackexchange.com/questions/2438510/can-i-find-the-closest-rational-to-any-given-real-if-i-assume-that-the-denomina :)

    posted in technical issues read more
  • jameslo

    @lead Yes. Here is what one of my plugins looks like on my Windows machine:

    Screenshot 2023-01-26 094100.png

    posted in technical issues read more
  • jameslo

    @alexandros He he he....I think David meant @seb-harmonik.ar. At least you were associated with a good idea :)

    posted in technical issues read more
  • jameslo

    @high_output-5000 said:

    @jameslo That sounds interesting! How do you set up the clone architecture?

    Maybe like this? https://forum.pdpatchrepo.info/topic/13500/signalrate-matrix-mixer Let me know if this is not right (and please explain how it's not right) and I'll see if there's a way to make it meet your needs if you can't see it before me. Definitely check out @oid's suggestion too.

    posted in technical issues read more
  • jameslo

    @high_output-5000 I think I've done stuff like this using nested [clone]s, e.g. the inner clones each represent a row for a particular column, and the outer clones represent the columns. The outer clones pass their column identifier to the inner clones. I'm just handwaving due to cocktail hour...let me know if you need more detail and I'll get on it! :)

    posted in technical issues read more
  • jameslo

    [bang~} bangs after each DSP block, but that's also when other control processing happens. If a GUI object generates a bang, does it run before or after [bang~] in that particular control processing block?

    I think it's before, and I'm guessing that [bang~] is the last control message processed before the next DSP block is processed. Check out this test:
    bang~ order.pd
    Screenshot 2023-01-19 222745.png
    I always get 0 when I click on the bang at the top. If [bang~] ran first, then its bang would clock the [timer] 1 DSP block later.

    Is my test and conclusion correct?

    posted in technical issues read more
  • jameslo

    The vanilla objects can't capture the raw MIDI bytes, right? By the time they come out as outlet messages, the MIDI messages have already been parsed. For instance, many of the MIDI objects have to be filling in the running status or else the channel info would not be output.

    Edit: Ooops, I'm wrong! Just read the help for [midiin]. Move along...nothing to see here....

    posted in technical issues read more
  • jameslo

    @pajzd You can spread the file loading over several audio ticks so that audio output isn't disrupted, see https://forum.pdpatchrepo.info/topic/13759/soundfiler-issue/7

    posted in technical issues read more
  • jameslo

    @adtubu I think there might be an issue with [metro 1] in your patch because it occasionally bangs twice between audio blocks. (background: control rate computations take place between audio blocks) Take a look at this test:
    metro block aligned.pd
    Screenshot 2023-01-14 095950.png
    If you click on the toggle twice, you will see that you generate more bangs than you would expect in that time period--approx 1.45 times as many, which happens to be the number of milliseconds in a 64 sample block. If you change the tempo to 64 samples or to 1.45125 msecs, then the number of bangs you get exceeds the number of blocks by 1, which makes sense to me because [metro] bangs as soon as you start it. So you are driving your recursion at a faster rate than you probably intended, and that rate is inconsistent.

    posted in abstract~ read more
  • jameslo

    @seb-harmonik.ar Oh I see, you're right. I missed that you would feed the additive term to the left inlet. Duh.

    posted in abstract~ read more
  • jameslo

    @seb-harmonik.ar I'm not sure if that's true. @adtubu's "integrator" is more like a recursive linear equation but [rpole~] is strictly multiplicative.

    @adtubu I thought of one thing that might be improved: @solipp pointed out to me that under some circumstances [lop~] never reaches the input value, even when the input is not changing. You could use [line~] or [slop~] instead which don't have that problem. But I use [lop~] that same way when I don't care whether it reaches the input value.

    posted in abstract~ read more
  • jameslo

    @adtubu The release is much longer if I play staccato than if I hold a key down--is that what you intended? Otherwise, things look and sound good to me, but I defer to others here who know more about synthesis than I.

    posted in abstract~ read more
  • jameslo

    @adtubu Can you post a patch demonstrating how it is used and what unusual things it does?

    posted in abstract~ read more
  • jameslo

    @ddw_music said:

    Oh OK... it's to implement "I just did something cool, now capture it right now."

    Honestly, I didn't know if that was @fintg's requirement, I was just surprised and annoyed that one can only access the delay line's internal buffer at audio rate (and was hoping that someone would prove me wrong).

    Here's an implementation of a circular buffer using arrays that has methods for instantly copying to another array, saving to disk, as well as the usual delay line business, without the 10s of noise issue. Look at the hoops I have to jump through! The extra memory I have to use! And the bit about the order of audio object creation, a dead horse I've previously beaten. It works by writing the input signal into a double-sized buffer at two points that are an integer number of blocks apart. The current contents of the buffer is the data between the two points. If you don't round the buffer size up to the next integer number of blocks, errors are introduced to the delay time depending on how [metro] decides to round. Maybe I should be counting [bang~]s instead.
    circularBuffer~-help.pd
    Screenshot 2023-01-12 102020.png
    circularBuffer~.pd
    Screenshot 2023-01-13 093147.png

    posted in technical issues read more
  • jameslo

    OK, file this under "there's no free lunch". I got it to save immediately, but the delay line is filled with noise after it's done. Try saving a 2nd time after waiting only a few seconds after saving the first time and you'll hear it. If you can tolerate waiting 10 seconds before doing another capture, then maybe this is a solution.
    delay as circular buffer 3.pd
    Screenshot 2023-01-12 114458.png

    posted in technical issues read more
  • jameslo

    @fintg It works for me, but as I pointed out you have to wait 10 seconds after you click [start( before you can open and read the sound file. Also, the rightmost output connection of [readsf~ 2] is not correct--that output bangs when it is finished. You want the middle outlet, but remember that you are only writing the left channel of the file--there's no connection to the right input of [writesf~ 2]

    posted in technical issues read more
  • jameslo

    @ddw_music said:

    Delay line data are, of course, available at any time by delread(4)~ with a positive delay time -- just not from disk.

    Not sure we're talking about the same thing. I'm talking about how the OP's patch saves those 10 buffered seconds of audio to disk in real time. Even if the file is closed immediately after the whole buffer is written, it still means the file isn't available until 10 seconds after you issue the command to save it. I couldn't find a faster way using Pd's delay lines, but I'm thinking it might be possible if you implement the circular buffer using an array.

    Edit: There also doesn't seem to be a way to copy the delay line's contents to an array other than in real time using delread(4)~.

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!