• ben.wes

    oh ... i didn't see the discussion here ... just built a little (and certainly dirty) patch for this after the discussion on facebook:
    patch_n_bitmaps.zip

    image.png

    it obviously becomes very slow with lots of canvases (and i'm already omitting the white pixels):
    2024-09-21 22-46-18.mp4

    ... plugdata on the other hand can deal with these quite easily - i creates rounded cnv rectangles though. :)
    2024-09-21 22-58-59.mp4

    (i scale them in that video - so this is not a glitch, but many wide rectangles)

    EDIT: this patch only works with a specific 3x8bit bmp format. so it would certainly look a bit funny with other formats.

    posted in technical issues read more
  • ben.wes

    you can check the help patch of this simplex~ external here (it's also on deken) - it includes very basic vanilla 2d and 3d oscilloscopes: https://github.com/ben-wes/pd-simplex

    posted in patch~ read more
  • ben.wes

    i realized that i obviously didn't follow all categories on this forum - so i missed your post and this response comes a little late. anyway: thanks for sharing! it reminded me of my approach for a vanilla pitch tracker. i now also realized that i didn't need a [block 1] for a 1-sample delay (which was there until today), but could use [rzero~] instead:

    image.png

    patch: zc_pitchtrack~.pd

    posted in extra~ read more
  • ben.wes

    @manuels said:

    Could certainly be optimized in some ways (especially using ELSE objects). But does it even work? I don't have a good method to test it, unfortunately.

    nice! - i like this counter for samples per phase:

    Screenshot 2024-08-14 at 23.22.05.png

    ... from what i tested: it behaves perfectly well up to nyquist - although also in this range, there are sometimes consecutive non-zero samples (which i'm still not 100% sure if valid. see the 1, 1 in the middle below. the blue graph is the scaled offset per phase).
    image.png

    posted in technical issues read more
  • ben.wes

    here's a completely vanilla version of the delay variant avoiding [expr~] (with some rather ugly hacks to achieve exact values of -1, 0 and 1). it works for all frequency input < nyquist (for nyquist, the > 0.5 check fails):

    image.png

    velvet-delay-vanilla~.pd

    EDIT: seeing now that this doesn't really add anything to @ddw_music's approach at https://forum.pdpatchrepo.info/topic/13317/looking-for-velvet-noise-generator/52 - except for my failed try to achieve non-interpolated values with delread4~.

    posted in technical issues read more
  • ben.wes

    @whale-av said:

    So...? please check this but [print~] produces output consistent with the rules as I understand them.....

    i think, you built a version at nyquist frequency! :)

    probably, i should read more into it (no time right now unfortunately) ... i'm not sure if velvet noise needs to meet the requirement of the random position of the impulses in each cycle. obviously, that's not possible anymore when a cycle is just 2 samples.

    the idea in the version mostly discussed above is exactly that though: there's one impulse per cycle and this impulse should be placed at a random position in its cycle with random polarity. and the cycles can be of any length (samplerate / frequency).

    this graph in https://acris.aalto.fi/ws/portalfiles/portal/13412521/applsci_07_00483_v2.pdf (page 4) is showing that quite well:

    Screenshot 2024-08-13 at 13.06.18.png

    EDIT: this brings up an important question though (which is also probably answered in the papers): are consecutive values of 1, 1, 1, -1, -1, -1 or -1, 1 allowed? not sure ... but these wouldn't be actual impulses anymore then, right?

    posted in technical issues read more
  • ben.wes

    @porres said:

    I can't feel any perceptual difference with just positive impulses, for instance....

    not sure if i understand correctly ... you mean you don't hear a difference between the mixed impulses and just positive ones?
    in that case, you might need to check higher frequencies and tune it louder. :)

    spectrograph~ (with db and log display) for both versions at ~3kHz:

    "balanced":
    image.png

    positive only (missing some lower frequencies):
    Screenshot 2024-08-13 at 09.17.31.png

    about the purpose: https://acris.aalto.fi/ws/portalfiles/portal/13412521/applsci_07_00483_v2.pdf talks about an application for late reverberation. i didn't completely read it, i admit - but i assume, for that purpose, the impulses should have both polarities.

    posted in technical issues read more
  • ben.wes

    @manuels said:

    @ben.wes Did you do the testing with non-integer fractions of your sampling frequency? You mentioned 3kHz at 48kHz SR as an example, which shouldn't make problems ....

    sorry for the confusion! - it weren't exactly 3kHz, since I'm setting the frequency with a logarithmic slider. tested once more with 3026.2Hz here now (which was probably also the value yesterday). i'm displaying the last 3 outlets here that i added to your patch (additionally offsetting the phasor for visual clarity):
    image.png

    Screenshot 2024-08-13 at 09.00.56.png

    posted in technical issues read more
  • ben.wes

    @porres said:

    that's gotta be really rare :) and only if the random chosen number is stupidly low... basically zero!

    ... not that rare depending on the phasor frequency and sample rate. for example: with a 3kHz phasor at 48kHz sample rate, the value of the phasor will increase by 0.0625 per sample (3000 / 48000). so in this case, for ~6% of the cycles, the value won't cross 1 (if the offset is below these 0.0625), since the phasor will already wrap when > 0.9375.

    not sure if this is a good explanation and completely valid - i'll wait for others to confirm or correct me. ;)

    posted in technical issues read more
  • ben.wes

    as far as i can see, all versions here potentially drop impulses? feels like this shouldn't be hard to solve - but i don't see how, i admit. and i probably also should check the previous versions in more detail to really understand them!

    another simple approach is this, where i'm trying to detect the significant wrapping for each cycle. this also leads to some dropped impulses - but it also adds some ...

    image.png

    Screenshot 2024-08-12 at 22.19.39.png

    patch: velvet~.pd

    posted in technical issues read more
  • ben.wes

    @porres said:

    [...] Haven't tested my patch like that, could you do that too @ben.wes?

    ... since it's based on the same logic of the randomly offset phasor crossing 1, it also sometimes misses impulses, yes (checked with ~3000Hz):
    image.png

    posted in technical issues read more
  • ben.wes

    @seb-harmonik.ar said:

    if the generated random phase is less than a sample increment and the phase wraps around, it will never be bumped to above 1

    certainly true in my case, yes - there are missing impulses:
    image.png

    posted in technical issues read more
  • ben.wes

    @seb-harmonik.ar said:

    * is more efficient than /

    yep, that's certainly true, thanks! - had measured this in the past as well (and commented above). i was just naively thinking that it might make a difference whether the argument is an int or float (which is the case for pow ... [pow 2] is faster than [pow 2.01] for example). but this thought doesn't make any sense here.

    posted in technical issues read more
  • ben.wes

    this doesn't add any new concepts and in case of a samphold~ value of 0, it will not cross 0 - so it's certainly missing a few impulses as stated by @manuels ... but besides that, i wonder if i'm missing anything with this simple approach?

    (in this case with ELSE's zerocross~ for upward-crossing detection - but a vanilla option would also be possible with 3 more objects iirc)

    image.png

    EDIT: patch: velvet~.pd
    EDIT2: ... and a noise value of 0 will not have a sign to copy in this case via x/abs(x), but result in a factor of 0 - so it will obviously prevent an impulse output. and if you know about the efficiency of (x+1)/2 vs. x*0.5+0.5, let me know. :)
    EDIT3: i guess that the /~ 2 is not a good idea here ... i saw in the past that pow~ is quite a bit faster with integer arguments - but i also saw that *~ is faster than /~. and although i don't know much about the details going on there, i assume that float division won't profit much from an integer divisor ... anyway, this is getting a bit off-topic.

    posted in technical issues read more
  • ben.wes

    following up here if anyone else is curious about this:

    while searching for more information on the hid "output report" structure of the dualsense controller, i stumbled upon a python library that implements all of this here: https://github.com/flok/pydualsense/blob/master/pydualsense/pydualsense.py#L445

    based on that, i finally felt confident enough to give it a try with a short report that should only change the bytes for the big motors:

    hidapitester --vidpid 054C:0CE6 -l 5 --open --send-output 2,255,87,80,160
    

    ... the last 2 bytes being the motor levels. aaaand ... it works! :)

    turning them off again via:

    hidapitester --vidpid 054C:0CE6 -l 5 --open --send-output 2,255,87,0,0
    

    posted in technical issues read more
  • ben.wes

    @oid thanks for pointing me to the option of using [command]! /proc/ is not available on macOS afaict - but in the [command] context, i might use a little tool i found here: https://github.com/todbot/hidapitester

    ... i admit that i'm a bit scared of destroying things with these low level hid commands. will try to understand of bit more before actually writing data!

    posted in technical issues read more
  • ben.wes

    i'm currently using the [hidraw] external on macOS to read inputs from a PS5 dualsense controller.

    it's a wonderful external and works great for this - but it doesn't allow to output hid data to the controller (to control force feedback etc.). any ideas if there is a solution for this that i might be missing (on macOS)?

    posted in technical issues read more
  • ben.wes

    @jameslo said:

    [...] In my (much less nice) version [...] I just used the final [s~] to get the resulting signal.

    after reading this, i mainly get the impression that your version might have been much less complicated!

    ... it seems so obvious now to just continue the chain from the last s~ instead of "sending" to nirvana and adding a logic to achieve the correct outlet~ result. damn. thanks!

    posted in technical issues read more
  • ben.wes

    so you're trying to run the current version 0.55-0?

    i admit that i can't make sense of all the output you get here - but this "livecast" thing seems a bit weird to me. is that some kind of plugin? ... did you try running Pd without standard paths and custom paths? you should be able to do this by adding the startup flags -noprefs -nostdpath when running Pd (see https://msp.ucsd.edu/Pd_documentation/x3.htm).

    posted in technical issues read more
  • ben.wes

    adding one more detail ... with a little logic inside the cloned patch, it's not necessary to set the audible instance id with an additional parameter - the max id can also be derived like this for example:

    image.png

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!