• ben.wes

    i just uploaded my first external to deken called simplex~. it's an object that allows you to sample simplex noise with multichannel signal input from 1 up to 4 dimensions. i'm pasting a screenshot of the help file here to give you a better idea. one rather simple application that i worked with quite a lot during the last months is a variation of scanned synthesis, where the 3d noise space is sampled in a spiral movement. you can also see and hear this (and change a few parameters) in the help file.

    simplex~-help.pd.png

    besides that, there are probably a lot more applications for this type of noise in Pd. looking forward to exploring them and happy about any kind of feedback or other demos!

    posted in extra~ read more
  • ben.wes

    update: this is kind of solved (or at least clarified) - it's actually a bug in pd. so no more need to investigate further here.

    posted in technical issues read more
  • ben.wes

    @whale-av adding to my previous comment: my assumption is that this might be a bug due to the novelty of this feature. at least i don't see how the type of outlets (multichannel or separate channels) could cause different output when they're transporting identical data.

    i made a simpler test patch here now which i'll add to an issue report ...
    compare-1sampleblock_mc-outlet.pd

    posted in technical issues read more
  • ben.wes

    no, snake~ is actually vanilla since the release of pd0.54 with multichannel features. :)

    posted in technical issues read more
  • ben.wes

    i was about to report an issue on the pd github - but since i really don't know what's going on, i thought i'd share this here first and maybe someone has an explanation for it ....

    i've been experimenting with a simple patch for random-walking the surface of a sphere. the current algorithm is not very elegant since it uses random steps that don't have equally distributed distances (but rather form the shape of a cube). i use 1-sample-send~/receive~ to feed back the current position for the calculation of the next position. the weird thing is that it works perfectly well if i output my coordinates with 3 outlet~s ... but the result looks different for the exact same algorithm if i output it via 1 multichannel outlet.

    so it seems like the outlets are affecting what's happening inside the subpatch?!?

    here are 2 screenshots for these 2 cases - with 3 outlets:
    Screenshot 2024-02-06 at 23.33.07.png

    with multichannel outlet (the coordinates are no longer on the surface of the sphere, but start to blur into a cubic shape):
    Screenshot 2024-02-06 at 23.33.34.png

    and here's the patch for testing (vanilla besides requiring Gem ... and the relevant part is in the 2 subpatches obviously):
    spherical_randomwalk_1sampleblock_mc-outlet.pd
    Screenshot 2024-02-06 at 23.35.08.png

    posted in technical issues read more
  • ben.wes

    Thanks for your responses! now that's interesting about the s/r performance - in this case, i get the following results (repeatedly tested again):

    [perf_meter]: pd_nop
        bangs  time(ms)  bangs/ms
      9603563    1000.0   9603.55
     
    [perf_meter]: t_f
        bangs  time(ms)  bangs/ms
      9987069    1000.0   9987.06
     
    [perf_meter]: send_receive
        bangs  time(ms)  bangs/ms
     10147908    1000.0  10147.90
     
    [perf_meter]: connected
        bangs  time(ms)  bangs/ms
     10711894    1000.0  10711.88
    

    Here's the patch if you want to check these on your side: test-performance-nop.pd
    image.png

    I updated perf_meter.pd with this additional newline for clarity - but as I said, I'm also not completely sure if this is a valid way of checking performance.

    posted in technical issues read more
  • ben.wes

    Not sure if this should be its own topic - but I also felt that it might be off-topic as a comment. I followed the interesting discussion/posts and inspiring patches in https://forum.pdpatchrepo.info/topic/14556/recursive-count-up-down yesterday. In the solution by @seb-harmonik.ar I was surprised by the [pd nop] usage since I would probably have used [t f] in cases where I want to visually structure or bundle float connections (this might also be a misunderstanding on my side in this case btw).

    On second thought, I assumed that the former option might be faster though since it's just a "prolonged" connection through inlet->outlet and doesn't need to check types or so like [trigger] might possibly do (I didn't check Pd's code here - which I would most likely not understand - and this is probably also a rather naive technical perspective).

    I sometimes test the performance of control rate solutions in my own patches with a little abstraction I created for this purpose: perf_meter.pd (this just repeatedly bangs a patch branch for 1s and counts the bangs) ... so I tried to compare the two with a simple counter - and to my surprise, the trigger seems to be faster (very slightly - but I get results like this repeatedly):

    image.png

    Now there are several questions:

    • does my [perf_meter] abstraction make sense at all?
    • if so - is there an easy explanation to this?
    • did I understand the purpose of your [pd nop]s at all, @seb-harmonik.ar? :)

    posted in technical issues read more
  • ben.wes

    Adding this here as well since I wasn't aware of it ... the download for the Pd64 version is also available from:
    https://puredata.info/downloads/pure-data (experimental releases on the right)

    posted in technical issues read more
  • ben.wes

    This is probably not a valid solution - but you can already work with 64bit versions of Pd. Artifacts are generated here:

    I tested this with the macOS_pd64 installer and actually get this result:
    image.png

    In that case, integers up to 2^53-1 can still be represented (which equals 9_007_199_254_740_991).

    The 64bit version explicitly states that it's still EXPERIMENTAL though. And if your patches rely on externals, these might possibly not be compiled for 64bit (yet) and therefore not be available through Deken (ELSE is not there for example).

    Besides that, the onset option described in the help of [tabread4~] came to my mind. This should give you a larger range, too.

    posted in technical issues read more
  • ben.wes

    Just a short follow-up ... there is already an issue since a few months describing this:

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!