Hello

If anyone can lend a pair of eyes on this abstraction it would be much appreciated,

I am building a text file to be later used with [text define -k $0-sequences]

The abstraction kind of works. but all of the information is one long line instead of each 16 digits separated line by line.

I also get this in the console.

$2: argument number out of range
$2: argument number out of range
$3: argument number out of range
$4: argument number out of range
$5: argument number out of range
$6: argument number out of range
$7: argument number out of range
$8: argument number out of range
$9: argument number out of range
$10: argument number out of range
$11: argument number out of range
$12: argument number out of range
$13: argument number out of range
$14: argument number out of range
$15: argument number out of range
$16: argument number out of range
$17: argument number out of range

This abstraction builds the text file by iterating through all of the possible sequences text files and using [add( message creates a "Master" sequence file which is displayed in the second screenshot.

Side Note*** I sometimes have to push the "Save Active Pat" button twice for it to work.

Hi,
Writing a [textfile] with cr removes the semicolon that Pd uses as a line break.
I think reading a[ textfile] with cr reinstates the semicolon.
If you intend to use [text define] later it may have been better to have used it here also.

@RetroMaximus Trigger is used to control the order of operations.

This is not good practice:

This is better:

Not good:

Better:

Not good:

Better:

@RetroMaximus Hi there, I see a couple of issues that might explain what you're experiencing (although no guarantees, since I'm just looking at a screenshot without being able to debug the patch...)

Dollar sign variables function differently in objects than message boxes. Your unpack & pack are objects, which means $1 through $16 are looking for creation arguments to be passed from the parent, not values that are being passed & unpacked from the list. What you probably wanted there is [unpack f f f f f f f f f f f f f f f f(, which will send out the 16 values in right-to-left order from the outlets.

The result being sent to the outlet is all ending up on one line of the textfile object because you are sending one "add" message with all of the values at once, whereas it sounds like you want to serialize them (textfile will create a new line for each new "add $1" message). Here's a simplification of everything between your [list] and [outlet] in the top screenshot:

[list]
|
|$1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16(
|
|add $1(
|
{outlet}

As for having to push a button twice for everything to work: that sounds very much like a problem with undefined execution order. Just for example: your [$7] object (again, I don't think a dollar sign variable is what you wanted there... it's looking for a 7th creation argument, probably failing & defaulting to zero, and effectively becoming a [f] object) is sending to a bang and the buildactivepatternPath subpatch, but you haven't defined the order. Basically anytime you need to control the order of operations (which is 99.9% of the time), use a trigger object, like [t b f] or [t f b].

Not to only dwell on bugs though... your vertical lines & overall patching style make for a very clean & readable patch, so nice work there!

@Balwyn Ok I completely thought it was the other way around I do remember reading that but obviously i had it twisted. Im going to change this now. Thx

I made a lot of corrections and I have the lines separated now and things are cleaned up a bit more. But now I am running into a issue where at the top of the text file always starts with a string of 0's and not the string that was first added using [add(. Its like the last added string always goes to the top or something its odd.

I tried playing with the count object in the first screen shot thinking it had to start at 0 but that didnt work.. Even tho in the screen shot shows it should start counting at 1 it seams to be either overwriting to 0 still or as I mentioned in the above paragraph whatever is last always ends up at the top of the file. How can I correct this?