• jancsika

    @ingox That's it!

    Now, suppose that instead of the current spam protection on this forum, the admin did the following:

    1. When a person wants to make a post, the forum sends a randomly chosen 16-beat pattern to the poster and requires the poster to send back the correct seed with their post
    2. The poster uses your brute-force method to compute the correct seed and sends it back with their post
    3. The forum software checks whether the seed actually computes the correct beat pattern. If it does then it lets the post through. If not, it blocks it.

    Step 3 is easy-- just set the user's seed, send 16 bangs to [random 2] and check if the output matches.

    Step 2 is hard-- in your case it took 4481 times through the loop to get the right answer.

    Step 1 is easy-- most OSes have a way to spit out an unpredictable sequence of bits

    Furthermore, if we add steps to the sequencer the job gets harder for the poster to find the seed, but it stays (relatively) easy for the forum website to verify the correct answer. That means the website can try different size sequencers to reach a nice balance between spam-prevention and user frustration.

    Congratulations-- we've just re-invented hash cash, the key ingredient behind Bitcoin payment validations.

    posted in technical issues read more
  • jancsika

    Here's a neat exercise that relates to hashing and cryptocurrencies:

    Take the following object chain:

    |
    [seed $1, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang(
    |
    [random 2]
    |
    

    We'll collect the output stream and use it to set the state of a 16-step rhythm sequencer.

    0 equals no drum hit. 1 equals drum hit.

    Now, consider that the Amen chorus might look like this in our crude sequencer:

    1 0 1 0 1 0 0 1 0 1 1 0 1 1 0 1

    Question: what seed value should we give to $1 so that our [random 2] outputs the Amen chorus?

    posted in technical issues read more
  • jancsika

    @ddw_music What is the patch you were running when this happened?

    posted in technical issues read more
  • jancsika

    @deframmentazione-geometrica

    Can anyone explain me why?

    The stack overflow detector counts the number of outlets that are triggered by a message. If the first outlet ends up immediately triggering another outlet further down the chain, that counts as 2, and so on until the bottom of the object chain is reached. When it hits the bottom of the object chain each outlet that forwarded on the message finishes up and subtracts from the total to get back to zero.

    If the total count exceeds a hard-coded limit, then Pd sends the stack overflow message. One easy way to hit the limit is to feed an outlet at the bottom of the chain back into the top. Pd uses the limit to keep the operating system's stack from overflowing and crashing the program.

    Quite simply-- you get a different behavior because you're adding an object to your recursive object chain. If you start a recursive loop with a different number of objects, you'll get different behavior as to where exactly the loop stops when you hit the limit.

    posted in technical issues read more
  • jancsika

    @allister How did you set it up in your *_dsp method? Are the arrays t_garray, t_array, array of t_sample, something else... ?

    Also keep in mind that the API will happily use the same memory location for both the input and output vectors.

    posted in extra~ read more
  • jancsika

    @JJLloyd That definitely looks like a bug. I'll try to reproduce later this evening and see if I can figure out what's going wrong.

    posted in technical issues read more
  • jancsika

    If you want you can send me a patch that triggers the problem.

    posted in technical issues read more
  • jancsika

    @allister Are there any reference materials for Walsh synthesis other than the Roads' book?

    posted in patch~ read more
  • jancsika

    @skautkurt That's the "import" object help patch.

    I actually like its interface a lot better than [declare] (I don't like flags in object arguments). But [declare] is really the standard object for loading libraries so I'd recommend using it instead of import.

    I added an issue for Purr Data about this in case anyone wants to attempt fixing a simple issue:

    https://git.purrdata.net/jwilkes/purr-data/issues/543

    posted in technical issues read more
  • jancsika

    What are the conditions?

    • "I want to trigger on of several paths based on a single float or symbol value" = [select]
    • "I want a single float message to make a path through the diagram based on its value" = [moses]
    • "I want a multi-atom message to make a path through the diagram based on the value of either the message selector or the leading float element" = [route] (note: leading float will get sliced off)
    • "I want a message to make a path through the diagram based on a calculation other than equality check" = reduce a calculation to 0/1 for [spigot] or reduce a calculation to an index and prepend it for [route]

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!