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

Edit: Must not have been quite awake when I patched that moses in, bet I thought I was being clever.

Once I understood that I can use [list split] to separate messages it became smooth. That both comma an semicolon made it a new message posed some problems.

The ELSE library?

Not really a tracker list... but check [else/score] and [else/score2]

But [text get] actually treats comma and semicolon the same way, ie end of message. The right output gives a number that indicates if the message was ended with a comma or semicolon. Since I want to keep the messages and rows in the text "synced", use the line as an index for the messages, this behavior becomes a problem. So either invent some custom separator or use [line split]. I always felt using [line split] a bit awkward but this seem to be the proper solution.

If you look at line 9/message 9 there are two commands. If I would to separate them by comma it would be regarded as two messages and would be output as message 9 (valAdd 1)and then 10 (goto 7).

I want to be able to add an arbitrary amount of commands per message.

Using line like this will only allow me to have one or two messages but it will at least send both commands in the same message (message index 9)

What is awkward is that each command must have the same format here (variable and value).

I imagine I can have an abstraction that I just update with new commands that I create and keep it separate from the texts ("fx1" here).

And also If you use [route symbol] with just the one argument ( multiple [route symbol] objects in parallel ) it can be updated through the right inlet if necessary.
David.

If you want commands with more than one argument things get more difficult since you don't want to always have to type in all those null characters or symbols, but it is not that difficult to create a simple editor which does it for you, especially now that we got [list box), I have one somewhere from when I made a tracker like thing years ago, I will see if I can find it later if you want to check it out.

If you really want commands with an arbitrary number of arguments and no nulls, use commas and exploit the right outlet of [text get]. This does complicate things regarding line number vs message number but making that [sel 1] into a [sel 0 1] and using the 0 outlet to bang a second counter for the line number might be enough?

It would be nice to see that tracker thing, if you find it please let me know.

My purpose is not build a tracker but just to have this little module that I can throw in wherever I want this type of modulation function. So its basically there already.

--

I plan to add a loop function with nn iterations as well. Thinking about it now, that may be a bit tricky because I would need a command with two values (target line, iteration).

Do you think it would make sense to use a format like this:

loop 10 = forever loop between this line and line 10
loop 10x4 = loop 4 times between this line and line 10.

(10x4 will be a symbol, needs to be split up, x is the decimator, and then 10 and 4 needs to be made floats again)

Or could there be a better solution?

My tracker thing started out almost exactly as yours did with and eventually evolved into this and finally into something rather close to a proper programming language. You might want to put the commands in the abstraction instead of the patch for ease of use or you can have library abstraction(s) that you can stick in the patch or dynamically load into the patch or abstraction through its arguments, or you might just continue on as you were and split your 10x4 symbol into floats, each have their advantages and disadvantages.

but check [else/score] and [else/score2]

@cfry did you check these?

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

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.

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.

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

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.

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

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.

@oid said:

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

Its midi programming language sort of, usually used when programming percussive instruments. If you have one closed and one open high hat you would like these to cut off each other. Not "poly". Same could go for the cymbals. So each of these would get their own exclusive group. High hat exclusive group 1, crash exclusive group 2 etc.

In my case I may have several instances of [tracky] (with different text files) triggering an fm synth. Here I want to have one or all of the variables to be shared. I may have a granular sampler controlled by several instances of [tracky] (with different text files), also sharing variables, but using another range (ex. 0-100, the fm synth using 0-1). The grain sampler also want its variables to be global, but not shared with the fm synth.

I could solve this by using different named variables for these different groups of global variables. But this will be convoluted and hard to get an overview. I think it may be better to use abstraction arguments to give them different groups: [tracky 0], [tracky 1], and [tracky] for not sharing variables at all.

This hotfix make the loop work as intended but just keep adding to the stack.

Could it be that since [v] does not output anything until it get a bang problems arise?

Also not sure how the stack is supposed to work in this case.