• sunji

    I was imagining the output of the sensor could be routed to a random int on a [pipe].

    [midi beat]
    | ............{rand int * sensor]
    | ......... /
    [ pipe ]

    posted in technical issues read more
  • sunji

    While you can upsample to make frames faster, you'll only be getting the same speed increase equivalent with dropping the window size. And what you gain in speed you lose in accuracy, starting in the lower frequencies. Doubling the sr with a 512 point window is effectively the identical to a 256 point window, just with twice the computations.

    One issue with spectral domain is that you need to poll a history of so many samples to infer frequency information. ie If you want 10ms response time (just the spectral analysis, not total overhead), the windowing will not even register 60hz tones.

    You can get away with smaller windows for higher voices. If you are tracking a piccolo or a violin, a 128 point window might be sufficient. 128 samples at SR 48k is only 2.6 ms of added latency, which is not too bad!

    posted in technical issues read more
  • sunji

    @Fauveboy In linux OSes, there is a nice value assigned to every running process, between 19 and -20. When processes are competing for resources, the nicer processes are left hanging while the lower value nice processes take precedence. You can dictate the niceness like so:

    $ nice -2 pd
    From the bash prompt.

    Depending on from where to where the data is being read/written, the system may experience bottlenecks. The rpi3 has LPDDR2 SDRAM which has a throughput which might be as low as 20Mbps. That basically translates to a 20MB file hoarding all RAM IO for 1/8th of a second.
    .

    posted in technical issues read more
  • sunji

    if you are in a linuxy environment, you can use the [shell] you can use 'date -r filename.pd' which will tell you the last modified time of the file in question. Why write a patch to replicate an inherent quality of files in the OS?

    posted in technical issues read more
  • sunji

    If you can find points in the set where you can handle dips for loading, that might be an opportunity to compose for.

    You can also mess around with the nice value of pd, which might reduce audio dips.

    Most modern rpis have 1 gig of ram, which you could load over 80min of cd quality stereo audio, and still have a couple of megs left over for OS and pd etc. How much rendered audio are you playing?

    posted in technical issues read more
  • sunji

    @sunji

    I misread the question. Forget the part about the histogram and just fit the spectrogram in a [rifft~] window.

    posted in pixel# read more
  • sunji

    How about histograms of the stills, windowed to fit in a [rifft~]?

    posted in pixel# read more
  • sunji

    @whale-av ocean waves are tranverse. if you add a a sawtooth LFO to your waveform it will mimic a transverse wave.

    posted in technical issues read more
  • sunji

    are you using [makenote] like in the video? I am not familiar with reaper, but your OSC messages received don't look like full midi information. i'd expect to see this:

    /note [i] 80 76 1
    /note [i] 80 0 1
    /note [i] 62 101 1
    /note [i] 62 0 1
    /note [i] 62 98 1
    /note [i] 62 0 1

    where every note on has a note number, a velocity and a channel, and every note on has a corresponding note off (velocity 0).

    posted in technical issues read more
  • sunji

    I'm not a Mac user, but I have reason to believe that you'll have to use a midi routing tool (sound and midi settings?) to patch the midi stream to PD. Then pd will accept the midi data through [notein] & [ctlin] and their family.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!