@ddw_music said:

Seems to me English is not up to the challenge here.

We just needed to identify the actual issue here, which is not patching but low level language. To do the sorts of things you want to do means you have to define an interface and a protocol, those things which high level languages like SC take care of for you. Pd has no concept of an instrument and if you want to use such a paradigm it is up to you to implement it. One way would be to send the instruments args to a master abstraction which then takes the necessary actions, a quick and simple example which is not fully fleshed out but should show the logic:

Started adding in my $0s halfway through. You would probably want a [text] in [register] to keep track of all this stuff and it can also keep track of values you can query for in the various abstractions and what not through their send methods. [stream] would need some more logic, needs a [receive] to start/stop it and probably would want a way to change its settings as well as an [iemguts/canvasdelete] so you can clean things up as your patch changes. [synth1] seems pretty complete and a solid instrument, I wouldn't change it.

@ddw_music Had some free time before bed so read your link, don't see anything there which would not translate to pd/data flow without issue.

each player needs its own [metro], and a way to pull from the stream.

like this?

All of this can easily be worked with each instrument being an abstraction using the right inlet on the array get or arguments or sending the pointer. Skipped some of the details but duration and getting the stream into the individual abstractions is straight forward enough and more of the same. I can't tell if I am missing something, life outside of data flow has become weirdly abstract for me, I am one of those sorts who really took to it. I am very interested in know what I am missing if I am missing something, I have been trying to cure my data flow myopia, it has become a bit of a disability in the last year or two.

Edit: Or is it that you just don't like that each needs its own metro? If so I think your issue is not with patchers/data flow but low level languages, pd is low level. But that is what abstraction and externals are for.

@ddw_music Right, like I said, I am terrible with contrived examples, I need context, I always confuse myself trying to deal with the unknown context. The only reason you have no iterator is because you are using [list split], [text] or [array] would be more suitable here, could move the headaches somewhere else but in my experience those headaches are from fighting data flow. [list] objects are not meant for sharing data and they are inefficient at it, could end up with loads of needless memory reallocations, [text] is not much better but when it reallocates you are only reallocating one object instead of two in your example abstraction and how many others in the rest of the patch?

I will read your link in the morning in case I am still missing the point, so feel free to ignore explaining it to me if that is the case and your link explains it.

Looking forward to examples -- I can't quite get the gist from this.

You can do stuff like unpack the canvas from the patch window and fill the window with Tk widgets instead, or have the Tk widgets and the canvas tiled or tabbed, make new windows, embed other patches into your current patch, lots of fun stuff. The abstractions do all the hard work and setup the stuff for communicating with your patch.

Edit: That was a silly place to connect the [text get].

@ddw_music said:

seems to me that's what the above is (just not folded into the subpatch).

You already have the send method, you just are not using it, [list store] gives it to you for free, as do [float], [int] and [value] , [text] and [array] have the send method to get a pointer to their data. I find it difficult to think of a situation were we can not build our abstractions around these objects and easily get access to the internal state of an abstraction to send data backwards or even "rewind" the patch but you have to plan it that way. Am I missing something? I am good at missing the point when it comes to contrived examples and fail to see beyond the example.

Not sure about pointers to abstractions, think I would need an example of your use case to address that.

Quite curious about that. Anything public to see?

Current project is actually getting a few of them into a shareable state, required me making a set of abstractions which is essentially a dialect of Tk since interacting with a text based language is awkward at best in pd. Believe the last hurdle in those abstractions has been passed and will finish them all up and document/upload them this coming week so I can get onto reworking the languages to use the Tk abstractions. They will get posted in the abstraction section as they become usable, I suspect only the Tk abstractions will have any real interest but I am curious to see if anyone uses my languages or they get people to develop their own languages. Thanks for the links, will dig into them this weekend.

Edit: forgot pic. And I did not quite plan that one out well, could easily cause an infinite loop or overflow depending on where [s backwards] actually sends to earlier in the patch. But I think it shows the logic?

@impression On Bela it is more difficult to use a frame buffer and those sorts of graphics but it is a BeagleBone running linux so you can do it but they probably will not offer much help in how to do it, they seem to try and keep Bela using just the Bela products, they don't want to have to try and offer support for the massive amount of third party peripherals out there and I don't blame them for that. On a pi if you use an OLED which there is a frame buffer driver for it will act like a normal computer screen once the driver has been loaded, the OS/kernel will handle all the details of how to draw stuff to the screen for you, it will draw your desktop when you startup and when you open pd it will draw pd.

I would recommend just getting one of those cheap pis and using it for a simpler project to get your feet wet and learn and get all your beginner mistakes out of the way before diving into the big ambitious project, it will most likely be quicker in the long run. Get a couple of the adafruit quad rotary encoder boards and some buttons/pads, make yourself a simple 303 style bass synth, use the onboard sound and you can probably manage it for $50 total with most parts (if not all) being able to be reused for your big project when the time comes if you want to save money and are willing to sacrifice your first born.

@impression As I said in your other thread, if you use an OLED which has a frame buffer driver for it you will be fine, you just need to load the driver and it will act like a normal display. Here is one for the pi: https://github.com/foldedtoad/raspberry-pi-oled but if you can find an OLED that uses the same chip or one of the others that driver supports and a normal I2C interface instead of the pi bonnet it will probably work just fine with bela. There are probably others but that is just the first I found, did not dig. Could also make the pi bonnet work withh bela without much work, just would have to connect it with wires/jumpers instead of plugging it right in like you can on the pi.

Why do you only have OSC? Just assuming that based off of the OLED you found or something else?

@ddw_music said:

The best I can figure out for Pd is:

In that situation I would say that [pd my-stateful-thing] should have a send method. But [value] is also good if floats, if symbols/lists then an abstraction which works the same as value but holds any sort of data is trivial, probably some externals which do that as well.

Regarding your live-coding dialect, would be curious to see it if you shared it anywhere. Not much for live-coding but it would be interesting/informative to see how you went about things. Most of what I do in pd is designing languages, it is not so bad but you have to go about things differently than you would in other languages, instead of designing a dialect of pd I design a language including the audio generation aspects, SC style server/client or a VM. Pd is a low level language and you need to treat it as such, work to its strengths instead of fight its weaknesses.

@impression Look for an OLED display with a frame buffer driver for it, there were a few such options when I looked into pi/bela a few years ago. There were a good number of options for small TFT and LCD displays.

@impression Moving the GOP might be the better option, have your sampler and menu in the same subpatch and when you click on the menu just move the GOP over to show the menu. Some information in a recent thread which should help https://forum.pdpatchrepo.info/topic/15031/expandable-gop

@porres said:

so I wonder what is not clear about all this.

It is a tricky thing to explain when your audience includes everything from complete layman to accomplished programmers. I can see now that it is all there and have been studying it and a few other sections trying to figure out what tripped me up and I think it is just a minor structural and terminology issues. What a selector is and does should be covered in the first paragraph instead of being split out between the first and fourth. This is the main thing the user needs to understand in this section and it should be laid out up front so anytime they refer back to this section it gets beaten into our heads. Maybe something like this?

Messages contain a selector followed by any number of arguments. The receiver of a message uses the selector to 'select' how it should proceed and handle any arguments. Selectors can be any valid symbol and arguments are anything that follows the selector and may be symbols or numbers (aka atoms). For instance "list a b c" has a "list" selector, which tells the receiver to process the arguments "a b c" as a list data type. This message is only composed of symbols but a list message can combine two or more symbols and/or floats.

You are right about keeping methods out of this section, the detailed explanation including methods should be in 2.7.3 which is almost there, just needs a few things like methods added in and probably simple definitions of things like object, class and method in context of pd. Maybe a reference to 2.7.3 in 2.4.1, "this will be covered in more depth in 2.7.3" or the like? The rest seems good to me.

I really hate doing documentation.

@mic automatonism might be of interest, they are all vanilla abstractions, can be installed through deken or https://www.automatonism.com/the-software

@porres said:

The "set" IS the selector. What you refer as a "method" is if the object understands that message selector. So it means it has a function (or "method") to deal with it. If it does not, it will say "no method for set", but it can also say "no method for symbol/float/bang", so it's the same for the special selectors as is with any other general selector.

And that is what I was missing, the old terse documentation which I learned from made it seem like selectors were essentially types and methods had nothing to do with selectors but the reality is that any valid selector has a corresponding method, that any object which accepts the float selector also has a corresponding float method? To put it into pd terms, a [f ] is essentially this on the inside:

If I understand this correctly, what a selector actually selects is the method for its arguments? If so I think this is why section 2.4.1 comes off as overly technical to me, it never tells us what a method is and how selectors relate to methods but it and pd's help files and pd's errors assume we will just understand this relation; for many of the seasoned programmers coming to pd this is probably a safe assumption but pd attracts a wide range right down to those who have no programming experience and for them it is quite abstract.

@gentleclockdivider I think that excerpt from the manual kind of gets overly technical, depends on how earlier parts of the manual handle things. Technically, everything in your patch is either a float or a symbol but selectors tell objects how they should treat it and if the object does not see a selector it recognizes it prints an error to the console. Selectors are not types, more like methods and I sort of used "selector" as type and made methods separate. The symbol selector has one argument, a symbol and each object treats the first item in a message as the selector to tell it how to deal with its arguments.

Perhaps @porres or another dev will chime in on selectors vs methods in pd, both are used in the help files, are they interchangeable? Should they be unified or distinguished better? That excerpt muddles the distinction, if there is one.

When the message is separated by commas , and send though a list , the console clearly shows these are seperate symbols , why then ?

Because those are three separate messages each being sent to [list] in order from left to right, [list] is one of the objects with no methods and applies the appropriate selector to the data it receives. Try that with an object which has methods like [list store], won't work, you will get three errors.

To be fair , I think pure data is a million times more complex than supercollider or anything else I have worked with

for years I had that same feeling about pd, spending some time in vanilla pd with no externals helped a good deal, got me over the hurdle with understanding the quirks of pd and dataflow.

@gentleclockdivider said:

The message c3 f3 a3 , the first selector is c3 and thus this message is an implicit symbol , correct ?

No, it is just a message, to be a symbol it would need the symbol selector. We have three selectors; float, symbol and list, when an object gets a message it checks for those selectors to make sure it is getting the correct type of data, if it lacks one of those selectors it treats it as a method like 'set' so your [list store] knows it should set its internal state instead of operate on the data and produce output. The alternative would be to have reserved words which you would have to escape or add a selector to, so if you wanted a [list] to store the message [set 1 2 3( you would have to do [list set 1 2 3( or [\set 1 2 3(. The pd way avoids reserved words which means we don't have memorize a long list of reserved words, just the three selectors and the mostly consistent ways they are handled.

Next , the message c3,f3,a3 , three messages after each other each with a symbol identifier

None of those have a symbol selector, those are just three messages. You can run those through a [symbol] instead of a [list] and for this sort of thing that is a good idea, explicitly states that it is a symbol so you don't have to trace the patch to figure out what is going on.

@ddw_music said:

but why then does [route] not automatically strip the "list" tag?

Lists were simpler things in the early days of pd with [pack] being the primary list object, there was no [list], so an object just to trim the selector would seem somewhat useless with how lists could be used and [route] doing the trim would be sensible. Quick look and [list] did not get added to pd until 0.39. Possibly a lack of foresight/planing or possibly things evolved differently than planned.

@oid That was a useless post. Good use of lists unpacking to inlets.

Can make much neater patches than [list store] and really gets you to structure your data and patch right to left which often results in a messy patch with [list store]. Interestingly both [i ] and [f ] show this behavior, which really seems useless but more than once I have found an error in a patch because of this and one of those errors which would have been difficult to spot otherwise.

@whale-av

@gentleclockdivider When you need to turn a list into a message remember that the only difference between them is the list has a list selector so [list prepend set] -> [list trim] will do the same and save you from endlessly having to add and remove dollar arguments from your [set $1 $2 $3...( messages as your list length changes, and it also works with listbox since it also has the set method.

If you are dealing with lists, uses list objects even if you are trying to turn that list into a message, it will make life easier and often you find you don't even need the message, the list objects will handle it all. Despite being able to click on them messages are not actually UI objects, hence their not showing up in GOPs, they are for constructing those internal messages which lack selectors like all those methods for [list store] and why they produce an error if you click on one with a dollar argument in it and needing a list or symbol selector in them when you want to use them for a list or a symbol.

@gentleclockdivider What would happen if someday the devs decided to add methods to [select]? it would end up breaking any patch which used [select] to match symbols without the symbol selector. You have to pick a path and stick to it or you end up with objects with exceptions and we have to memorize all those exceptions or constantly get bitten by them.

@gentleclockdivider List and symbol objects apply their selector to anything sent through them, the exception being [list store]'s right inlet which has to deal with methods like [set 1 2 3(. The selector tells the object how it should deal with the incoming data. You can just use [route - kick hat] instead of [select] and have it work just like in the Max/MSP version but then you will need a [list trim] after your [list store] to strip the symbol selector. Or you can just put a single [symbol] before the [select] and just run everything through it including the [list store] which is safer than individual as needed [symbol]s, won't have to worry about selectors at all this way.

@kazeko -audioaddoutdev should work here. Any errors printed? What is the output of -listdev when your interfaces are connected? You can save the pd log to a file when running headless by starting pd up with -stderr 2> log.txt, using that will overwrite log.txt with the stuff pd would normally print to the console, -stderr 2>> log.txt will append to log.txt instead of overwrite it.