• noise

    Hmm, well it's interesting, but it behaves not in the way I thought of. The examples I gave (and marked with smilies) work as they should; the problem occurs in the moment when messages are too near to each other.. (e.g. lists or even small delays)
    It can't be that hard; I've seen way more complex behavior.

    posted in technical issues read more
  • noise

    Hmm, so it does solve the misbehaviour i tried to mark with the smilies, but changes as well the entire behaviour and makes the tones now sequential rather then intertwined. The examples on the top of my main patch worked before like they should: they intertwine smoothly, except when to inputs are send at a near distance in time (which can be shunted a little with the [env~] window size).
    So maybe i described it not correctly which lead to a missunderstanding in the favourized behavior but i really don't know how to make it more clear.

    posted in technical issues read more
  • noise

    yes, it is same [dia]; it's a bit similiar to [moses] but with a switch.
    --> playground.tar.gz
    feel free to use it as you like.

    posted in technical issues read more
  • noise

    i am so sorry @whale-av, here hopefully the entire playground.tar.gz. it's sometimes a bit needle-in-a-haystacky to find every abstraction..
    i really don't know how to describe it better so the patch is my last chance..
    my wish is to cascade tones.. and none of each one shall disturb the others..

    posted in technical issues read more
  • noise

    =) Thanks for the PS.. I was thinking about going to sleep because i did not know what to answer..
    Well, i wanted an abstraction that accepts as inlet a frequence (not a list!). inside sits a chain of enveloped oscillator abstractions that give the value to the next in the chain if they are already triggered (resp. not silenced).
    It might be described as or more smooth tonal resp. landscape effect when changing a frequency.
    I encountered the problem when sending with [send] from different instances (maybe "in the same logical moment"), so i patched the mechanism with which i tried to realize it (and found the same defective behavior).
    Maybe i got just a conceptual flaw in it, so if you give me a hint how you would realize such in a different manner i'll patch it.
    I'll have a sleep now; thanks for being so patient and interested, David - it's not the first time.

    posted in technical issues read more
  • noise

    Thanks for your fast reply, David.
    I don't get exactly towards where you were nodding me, maybe i have to think more strictly what the patch is doing.
    Some appendix: I chose the topic because if i reduce the pipe delay (let's say to 4) the problem occurs again, but i can circumvent it on the other hand when reducing the window size of env~ (to let's say [env~ 2 1]). The thing is: i cannot really reduce it to a window size where simultanous values get split (to articulate it in terms of my example).

    posted in technical issues read more
  • noise

    hey folks,
    i wonder if someone can help me please.

    synopsis: i wanted for an instrument to chain some oscillators, so if [inlet] is some frequency i hand it over to the next [osc~] which [env~] (via [vline~]) is [==0].

    problem: if there are simultanous inputs, some get ignored.

    i made a patch which reproduces the phenomenon, so if someone has any idea or suggestions i would be very eager to hear it.

    p_latency.pd

    very much thanks in advance.

    posted in technical issues read more
  • noise

    wow, nice lib, hidden in plain sight, thanks.. i think i'll have to dig deeper into my directory trees..

    posted in patch~ read more
  • noise

    normalize~.pd
    sup.pd
    Dear audiomagicians, i wanted to have a nice and clear normalizer in order to avoid fiddling with amplitude factors. So my idea was to get the maximal amplitude and multiply everything with its inverse. After reading the env~ documentation and some trying i guessed correctly that the dbtorms had to be multiplied by sqrt(2), so i wondered if somebody can give me a hint, why i need to do that..
    Anyway, if anybody has some suggestions, maybe for normalizing not just "upwards" resp. to recognize if the factor of multiplication (MF) maybe has to increase to fit the inlet~ between [-1,1] or some other feedback - hand it over! :)

    posted in patch~ read more

Internal error.

Oops! Looks like something went wrong!