Pretty self-explanatory question. All I want to do is fill an array with a straight line y=x. What I attempted to do was just make a simple counter, and at each step send the number into the left and right inlets of a tabwrite object. Then a spigot is used to make sure the counter stops at some number (will come from another variable but for now is just set to 590,538). Ok, seems really easy but my code got confusing quick and is not working. When I print out the values outputted from the float it starts at 332 and counts down to 0.

I have included the ungodly mess that I put together so far. I am open to easier solutions (I am sure you could do something with [line]) but also want to know what specifically is wrong with this code.

Thanks for the help!

_Toad

@ToadYolo

Ok not sure what was going on but I deleted and replaced the [+ 1] object and it is counting up, not down. Now it just stops at 333 and says stack overflow.

@ToadYolo Your code is smarter than Pd as it has a mechanism built in to prevent an infinite loop. Pd wants to calculate from the beginning to the end and not have an infinite loop. Therefor is detects if the same object is called so many times within the same computational run and stops after that giving the error.

There are several objects that break the loop. They create another computational run.

In Pd vanilla these are [delay], [pipe] and [until].

But as you can see [pipe] is somehow slow, [delay] probably is also somewhat ugly. [until] is made for this kind of iterations:

count.pd

Just be careful with [until]. If it gets a bang instead of a number and is not stopped by the code, it will create a real infinite loop and will make Pd crash.

As you are using Pd extended (which is discouraged as it is out of date) you can also use [uzi]. It is from the cyclone external so you can also use it with Pd vanilla + cyclone. It is basically a combination of [until] and a counter.

First of all, it's better to use [trigger] instead of fan out connections (one object connected to many). Second, never make a counter where [f ] connects to the left inlet of [+ 1] and the latter also connects to the left inlet of [f ]. [+ 1] MUST connect to the right inlet of [f ] otherwise you get an infinite loop, hence the stack overflow message.
You should use [until] to drive your counter and either feed [until] a number of iterations, or if you send it a bang, make sure you have some mechanism to stop it by sending a bang in its right inlet (e.g. use a [sel]).
To fill in an array with a straight line do this:

[590538( <- this is a message
|
[until]
|
[f ]x[+ 1] <- [f ] connects to the left inlet of [+ 1] and [+ 1] to the RIGHT inlet of [f ]
|
[t f f]
|     |
[tabwrite array2]

EDIT: I guess @ingox was typing an answer the same time with me, so I didn't see it before I hit submit....

yay, thanks for the help! much more elegant solution, now I can move on to getting the rest of the patch working.

_toad

A very fast and simple method i almost always use is writing tables in the audio domain.
There are examples in the docs that showcase this, one i can remember is the one about transition splice oscillators...
I'll include a slightly descriptive version of my goto setup: tablewriter.pd
(That uses a couple of audio-maths objects from externals for shaping the slopes i'm writing, but if you are using extended those are probably included in your library.)

The one flaw with this is that you will start loosing 'accuracy' with bigger tables. if you are writing a 500'000+ index table you will need to fiddle a bit with the frequency and phase onset of the phasor~.
But for fast prototyping with transfer-functions it is a very good, and fast, alternative!

Happy hunting!

@Booberg I am not that firm in the audio domain. Isn't it that the audio signal is subject to block sizes? [until] is instant, i.e. in zero logical time.

Your patch crashes my Pd by the way

@ToadYolo said:

When I print out the values outputted from the float it starts at 332 and counts down to 0.

As others have pointed out, your original patch uses recursion for the loop.

Recursion means that you are feeding the result of a calculation -- [+ 1] -- into the HOT inlet of the previous object. "Hot" inlet means that the chain of processing must continue immediately, and it must remember all of the steps. Remembering the steps takes up memory, which is why recursion depth is limited.

So recursion is usually something to avoid, unless you're sure that it's the right way, and you're sure that you're doing something to stop the recursion before hitting the depth limit. (590,000 cycles is way, way beyond the limit -- Pd recursion will never be able to handle that many.)

The solution from Alexandros avoids recursion by putting the [+ 1] result into the float box's COLD inlet -- so, this result has been prepared for the next "bang" from [until].

This does have to do with the "counting down" phenomenon.

The left side is counting recursively. The [t f f f] toward the bottom is there to show the impact of different order of execution. For every recursive iteration,

• First print the "before" value;
• Then calculate the next value and recursively loop back -- so this next value will print "before," and calculate its next value and loop back, printing "before" again and so on.
• Only after the [moses] has stopped the recursion can it then backtrack through all of the recursion levels to print "after" -- but now it's backtracking. So the first "after" to print will be the last value processed, continuing in reverse order.

before: 0
before: 1
before: 2
before: 3
before: 4
after: 4
after: 3
after: 2
after: 1
after: 0

So, using recursion as you were doing, if you simply add a print box after the fact and connected, the order of execution is the same as my [print after] box.

Doing it the optimal way, with [until], then the recursion disappears and the printed output is more intuitive.

before: 0
after: 0
before: 1
after: 1
before: 2
after: 2
before: 3
after: 3
before: 4
after: 4

One of the problems here is that (AFAICS) Pd training materials do an absolutely abysmal job of prioritizing the materials. It happens that section 2.3.3 of the manual does illustrate the basis of a correct counter (although it's incomplete), but -- while this concept of feeding a value back to a cold inlet is absolutely critical and the foundation of a large percentage of what you will do with Pd, it's mentioned almost in passing, and the text does nothing to highlight how absolutely critical it is (and it really should present a complete, usable counter, with initialization and a termination condition -- but it doesn't do that either).

I have some decades of experience with text-based programming, but it took me months to understand how to count properly in Pd, and more months to extend that concept to related use cases. I'm sure that's partly because of some degree of pig-headedness, but I don't think that's a complete explanation. The manual is simply not very useful pedagogically

hjh