• ddw_music

    @Tractor

    I don't have anything working right now, but:

    https://github.com/jamshark70/Ofelia-Fast-Prototyping/commits/topic/shader-support

    This is a fork off of 60Hz's abstractions, including an (experimental) [of.shader] object.

    I think a green screen would be pretty easy to write as a fragment shader, and this would hook it in.

    hjh

    posted in pixel# read more
  • ddw_music

    I wonder if anyone recognizes elements of this project?

    xijie-clip.gif

    This is a final project in a Pd class... the thing is, I didn't teach GEM this semester. So, either one of these students is extremely independently driven and has been playing with GEM on his own (for quite a while, it would seem), or they downloaded a project from somewhere.

    I don't want to be too suspicious... but, no harm to ask.

    Thanks,
    hjh

    posted in pixel# read more
  • ddw_music

    @raynovich said:

    When doing audio processing, a few milliseconds error can cause a digital click. I was worried that the digital processing would be compromised. As I am looking into granular synthesis, it is a bit overwhelming figuring out how to make granular synthesis work without creating lots of problems.

    Avoiding clicks in granular synthesis is mainly a matter of applying a windowing envelope to every grain. If every grain ramps up from silence and back down to silence, then there is never a sudden transition.

    Just the other week, I demonstrated in a class a way to do that: each grain runs a line~ from 0 to 1 and this splits to two places:

    1. Map this normalized range onto the desired range of samples to pay back, and tabread4~ the source.

    2. Map the normalized range onto another table containing a Hann window, and tabread4~ that.

    3. Multiply, and... a clean, windowed grain.

    hjh

    hjh

    posted in technical issues read more
  • ddw_music

    I don't believe any control-domain time measurement will be 100% accurate. If it's off by a couple milliseconds, that sounds normal.

    You could write audio into a file and measure the samples between attacks. That's about as good as it's going to get.

    hjh

    posted in technical issues read more
  • ddw_music

    @jameslo said:

    @ddw_music you could also just replace the impulse generator with [set 1(

    That's a tempting optimization, but not exactly the same.

    pulses-not-the-same.png

    The left hand side models the behavior of adding energy into a system -- if the system hasn't decayed to a resting state yet, energy will accumulate. The right hand side simply obliterates the energy that was in the system beforehand. Both are valid behaviors depending on the circumstance, but, not identical.

    hjh

    posted in technical issues read more
  • ddw_music

    @solipp said:

    you could just taplay~ an array with one sample at 1

    Ha, indeed it won't get any simpler than that.

    Thanks, all --
    hjh

    posted in technical issues read more
  • ddw_music

    Discounting the brief delay, the highlighted bit appears to produce a single Dirac impulse in response to a bang. (The rest is a pd-vanilla version of Decay.ar from SuperCollider.)

    Is there a better way?

    pd-decay.png

    hjh

    posted in technical issues read more
  • ddw_music

    @oid said:

    So best practice is not to name the objects directly with arguments but indirectly with comments.

    Well, the best would be to give properties to inlets and outlets, including a name, and then in the parent patch, show tooltips when hovering over the corresponding hockey puck.

    hjh

    posted in technical issues read more
  • ddw_music

    @Obineg said:

    one reason why i find it "strange" is that it causes an inconsistency between the externals paradigm and the patch paradigm, since you cant have inlets in your abstractions which takes both signals and messages.

    In fact, you can connect a control to a signal-rate inlet~.

    This abstraction is kind of dumb, but it makes the point:

    pd-simple-osc.png

    Then, here, the left-hand side patches random numbers (generated in the control domain) into the slot defined by the signal-rate [inlet~]. And, the right-hand side patches a signal-rate LFO. They both work.

    pd-simple-osc-main.png

    What would not work is to patch a control and a signal in simultaneously: the signal will overwrite the control.

    about your example... no idea how that same implementation would perform in pd? but in max, if you´d cut off a signal objects from DSP, for example by shutting down a subcircuit, the last value of the now stopped signal would remain in the input buffer of all connected objects.

    It appears that, when you connect nothing to [inlet~], it already holds its last value and doesn't reset. You can test that, in the sample patch above, by deleting the signal connection into the right-hand side instance of the 0529 abstraction. If it went to 0, then the right channel would be silent. Instead, it holds frequency.

    So it seems it already works as you specify. (That's different from what whale-av said -- which is understandable -- as others point out, Pd help patches lost some key details so it's easy to get confused about this kind of fine print.)

    This also means that there really is no reliable way to tell if something is connected or not. You can specify an initial value for the [inlet~], but if you connect something and then delete the connection, this initial value will be lost and not reset.

    hjh

    posted in technical issues read more
  • ddw_music

    @Obineg said:

    i would have found it more logically that inlet~ would only get activated when you connect something to it, since patching requires a recompile anyway.

    the way it is you are creating a lot of signal connections for nothing for some abstraction designs.

    A counterexample:

    Let's say you're making a mid-side encoder abstraction: two signal inlet~'s (left and right), and a [+~] and [-~]. The left inlet~ goes into the left inlets of the two math operators; the right inlet~ goes into the operators' right inlets. So the adder produces the mid signal, and the difference operator produces the side.

    Now you put the abstraction into another patch, and connect a signal to the abstraction instance's right inlet.

    By your logic, the operators' left inlets should be deactivated. But the operators still need to calculate. (Passthrough isn't an option because, in this contrived example, the [-~] side signal should be phase inverted relative to the mid signal -- the [-~] must be doing 0 - R.) To calculate, the operators need two inputs.

    At this point, software designers would have to weigh the CPU cost of passing zeros (arguably this is likely to be minimal) against the added complexity of maintaining active vs inactive connection states. Considering that it's easy to underestimate the maintenance impact of code complexity, it actually is a legit decision to accept a small CPU cost in exchange for more straightforward logic.

    I don't find it strange at all.

    hjh

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!