Hi,

I want to be able to add commands to a list and step forward through it, similar to a "channel" in a tracker style sequencer.

I figure a good way to do it is to just use [text].

Or? Could there be a better solution? Or even abstraction. The ELSE library?

...

Image for reference:

All good

@oid where is [list-drip] coming from? Deken says shadylib but it is not there.

edit: never mind, I found it in list-abs

trackthing.pd

Can you help me to get this working? I tried to debug with [print] but I could not figure out the local variable hierarchy. (screen shot and patch is for visual reference)

And then maybe we can do a few new commands so I can handle it?

On a side note: No need for sudoku today! Pd and @Oid will keep me fresh now when chatgpt now make so complex code for my arduinos that I can not read it anymore.

@cfry The abstraction part is supposed to be run with $0 as it's argument to pass the parents dollar zero so those commands in the parent patch can communicate with it. Change those $1s to $0s if you want everything in one patch, or the $0s into $1s if you want commands in both the abstraction and the parent patch and all should be well. It will be atleast a few hours before i can offer patches, computer died right after yesterday's post so have to setup the new one and do all that stuff which goes with a new computer. Once you get the basic functionality working it will probably start making sense.

@cfry it probably picked up [list-dripdex] which is [list-drip] w/ index
I think list-abs could use a rewrite using the 'new' [list] objects..
I recommend just installing zexy and using [drip] though.. externals will always be faster than abstractions

@cfry Took care of the dollar args for you and fixed a small oversight in the previous which made it not work for commands with more than one argument. Also added a simple trace which prints stack size, command, and the top 10 elements on the stack, should help you in figuring what is going on. The [s $0fpush] is the same as $0push, nothing fancy there, it was just a simple way to make the trace slightly easier to read.
trackthing.pd

Edit: fixed a bug.

@seb-harmonik.ar

I think list-abs could use a rewrite using the 'new' [list] objects.

I started in on that but realized that the overall design of list-abs is an issue, often what takes 5 list-abs abstractions can be done with a single [list store] and some glue, some can be replaced with [list store] and a message and have no need to be abstracted away. I think a good [list store] tutorial and a much smaller (more thought out and planed) replacement for list-abs would be a better idea. List-abs is fine as it is for keeping old patches alive.

@oid Thank you so much. It is coming along quite well.

Question time:

Could we make a 2 argument command, like the loop function? I could not figure out how to use 2 arguments.

Is there a specific reason why you used the value object? I found use for it, but I am just curious.

How would you send the final out of the patch? As I patched it now I I am not using the value object for this.

I think I may add more values later, like val1 val2 val3.

I commented all over in to help me understand what happens. Is there any spots where I totally misunderstood it?

If there are any awkward edits I made feel free to correct it or point it out. Pointer about suitable syntax is also appreciated.

trackthing-oid.pd

@cfry Doing two arguments is just changing how many arguments you pop off the stack and replacing the [route bang float] after the command receive to [route bang list]. So a loop command could be made like this (untested and not even fully thought through):

I used [value] because add works off the last value that was output and [value] keeps things neater than tying lots of stuff to a single [float]. In this case you don't need to use [v $0val] to get the output for val, it just stores the float for add, same, and any other command you want to use it for, sending the float to both [v $0val] and [s $0out] is exactly what I would do in this case. I don't think $0-same will work as you expect, there is no need to pop for that and out is getting a bang instead of a float, just need to do [route bang] -> [v $0val] -> [s $0out].

Your comments look to be correct. [r $0stack] is used for the trace but it is useful for other things, you can have a print command which just bangs the message [send $0print( to [s $0stack( and then a [r $0print] connected to a [print] so you can check the stack's condition in those cases when things did not work as planned and you did not have the trace on. Notice the send message is to $0print and not $0-print, receives with the $0 hyphen prefix are only for commands and you will get into trouble if you use that prefix for non-commands. In this case we send the print to $0print instead of $0-print because if the stack is empty it would output a bang which would bang the message again and send you into an infinite loop. Remember to save before testing new commands, it is easy to miss an obvious loop like this.

We prepend to stack instead of append because that means we always get to do [delete 0 $1(, if we appended we would have to keep track of stack size and then subtract how many to delete so we can do a [delete $1 $2(, just more efficient to do it this way in pd land. There is a bit of a flaw here as well, think about what happens if you run the line 1 2 3, one is pushed, then two, then three, so three is top of the stack and the contents of the stack is reversed as 3 2 1, as it should be, the issues is if we have a command which pushes more than one value onto the stack. If you had the command which just bangs the message [1 2 3( to [s $0push] you would have one as top of the stack instead of three so in commands you need to send your lists backwards. Slightly annoying and could be fixed but would be less efficient, so I just remember that when patching commands which push a list, the list needs to be backwards or it will cause confusion elsewhere.

I will do another post later tonight or tomorrow going into the rest and elaborating on a few things.

Edit: Suppose that loop command only works for looping to a point earlier in the program, which is probably workable but perhaps not ideal. We will deal with that in the next post and start really exploiting that this is a programming language and will save you work as any programming language should. Trying not to dump too much on you all at once, next post will be a big one. Or maybe you are already ahead of me? can't quite tell.

Edit2: No, that loop will not quite work, for got to resend the float to $0-goto on each iteration, only loops once.

@oid said:

I used [value] because add works off the last value that was output and [value] keeps things neater than tying lots of stuff to a single [float].

Yes its convenient, I have tried to add a global function to share the variable "var" between several instances. [v] is good for this purpose. Use case: for example one instance with a list with "add" +1, and another instance with a list with "add" -1. And they are triggered independently.

It would be good to be able to have different groups (like "exclusive" groups).

I also see a use case for several "var" (var0, var1, var2, var3 etc)

...adding a global mode, exclusive groups, idle-reset, and so forth are configuration settings, not part of the live output. Question is where this should go. In the text file also? Or in another text file? Or if they are just a few, maybe just as arguments in the abstraction. The config settings should be retained. It would also be good if one could write the text to use as an argument in the abstraction: [tracky mycommands]. Not sure how to do that.

Slightly annoying and could be fixed but would be less efficient, so I just remember that when patching commands which push a list, the list needs to be backwards or it will cause confusion elsewhere.

that is fine, I just need to include some instructions on how the syntax goes.

We will deal with that in the next post and start really exploiting that this is a programming language and will save you work as any programming language should.

The problem that arise is that when I start to improvise I kind of "break the (your) concept". And I would like to avoid ending up in another patch that is so messy that I can not use it if I bring it up after a half a year or so. Lets continue working on it!

Edit2: No, that loop will not quite work, for got to resend the float to $0-goto on each iteration, only loops once.

I have given your loop code several shots but I can not figure out how to get it working. I managed to (in a messy way) to have it repeat for x times, or loop forever, or loop just once. But never loop x times and then be ready again to to loop x times.

Current patch:

tracky.pd

@cfry said:

The problem that arise is that when I start to improvise I kind of "break the (your) concept". And I would like to avoid ending up in another patch that is so messy that I can not use it if I bring it up after a half a year or so. Lets continue working on it!

You are definitely getting parts of it and seeing how to develop it but there are parts you don't quite have yet and I can't quite identify what those are so I can explain things. I made a sizable patch that adds a lot of commands but last night I realized I went to far and it would probably confuse things for you, so I will reduce it down to just the things you mentioned, I will follow your lead.

Passing the text name as an argument is just a matter of using your dollar arguments, [text get $1], but you will want to tweak your input for text symbols some.

So our right inlet for text symbols goes to a send now so we can easily access that text anywhere in the patch, like in our commands, and we also reset the counter which uses a value for its float for the same reason, we will want to be able to access and change its value from commands. "pc" is short for program counter and it is important that we increment its value before sending a float to the text get otherwise if we change its value in some command it will get overwritten, so having a [t f f] here is almost a must. This also means that [v $0pc] points to the next line to be run and not the one that is currently being run, this is important, fairly useful, and occasionally irksome.

The left inlet has change some as well, we have a [route bang float], bangs and floats go to the counter so we can increment the program or set the next line to be run, the right outlet sends to our [list-drip] which enables us to run commands from the parent patch so when things don't work you can run that print command to print the stack and get some insight or just run commands from a listbox to test things out or whatnot. We also have [r $0bang] on the counter, this lets us increment the counter immediately from a command and start the next line. And finally we have a new outlet that bangs when we reach the end of the text file so we can turn off the metro in the parent patch which is doing the banging, reset the counter to zero, load a new program, or what ever you want to do when the program completes. Middle outlet I did away with, globals can be done as a command, as can most everything.

Variables we can implement with some dynamic patching and a simple abstraction to create the commands for setting and getting the value of any variable.

This looks more complicated than it is. If we have the line var val1 10 in our program it runs the var command which bangs [v $0pc] and subtracts 1 from it to get the current line from the text holding our program and then appends our $0 to it giving us the list var val1 10 $0. The first message it goes to creates an instance of the var.pd abstraction in [pd $0var] with the second and fourth elements of the list as arguments, val1 and $0. Second message sends $3 to $4->$2, 10 to $0->val1. To finish off we use that new $0bang receive to bang [v $0pc] so we don't execute the rest of the line which would run val1 pushing 10 to the stack and then push another 10 to the stack. Variable name with a > prepended to it is the command for setting the value of a variable, 22 >val1 in your program would set the value of val1 to 22, val1 would push 22 to the stack. If we could see how pd expands all those dollar arguments in the abstraction it would look like this:

Now you can create as many variables as you would like in your programs and a couple tweaks you can have the abstraction global.pd and subpatch [pd $0globals] so you can have the line global val2 0 and get a global variable that all instances of tracky can read and write from. There are a couple catches, each variable definition must appear on its own line with nothing else after it and with our simple parsing there is nothing to stop you from creating multiple instances of the same variable, if you run the line var val1 10 a second time it will create a second abstraction so when you run val1 it will bang both and each will push 10 to the stack giving you an extra 10 and screw up your program. We can fix this with adding a registry to the var command which searches a [text] to see if it has been created already, something like this after the [list $0] should do it:

And you will want to create a command to clear all variables (and the text if you use it) by sending [clear( to [pd-$0var], or get fancy and add another command in var.pd which bangs [iemguts/canvasdelete] so you can delete individual variables. Using [canvasdelete] has the advantage of not needing a registry for variables, you can just always run ```delete-<variable name>, or what ever you name your delete command, before creating a new variable. Each method has advantages.

Your loop does not work because the unpack needs to go into the left inlet of the float, that triggers the first loop and causes it to go back, each time the program gets back up to the loop command it increments [v $0loopi] until the select hits the target number of loops which sets $0loopi to -1 which ends the looping.

Not sure what you mean by groups/exclusive groups, can you elaborate or show it with a patch?

None of the above has been tested, but I did think them through better than I did the loop, fairly certain all is well but there might be a bug or two for you to find. Letting you patch them since we think about how things work more when we patch than when we use a patch. Try and sort out and how they work from the pictures and then patch them together without the pictures, following your understanding of them instead of your memory of how I did it. And change them as needed to suit your needs.