Hmm.. @whale-av. You could route out all the other selectors you have. Or play around with some form of type checking..

Also, in regards to editing pd's messages. I'm pretty sure that is entirely in c, so you would have to fork pd and recompile it with your changes.

Since messages are one of the original things in pd, I bet its tangled up in a lot of other code... but it might not be hard. If it were me though, I'd just try get used to the [list prepend ] -- [list trim ] combo, as you can have mutating messages with just a list object.

Really the only things I use messages for anymore are loadbanging things before audio starts, and string manipulation. With strings, I use it rarely too; I tend to just use [list fromsymbol ] --- logic --- [list tosymbol ].

It looks like more clutter, and it can be weird when you have an object that needs a selector or doesn't, but its faster than plain messages. You can store big messages too, like [list prepend set $0-sine ] -- [list trim ] will set a tabread object.

edit:: you can do anything the zl objects can do with the list objects and some logic. Try making something recursive. Careful not to crash pd though. The list-abs library has some premade patches, some are bulkier than I would use, so you can trim them down to your liking.

Well, pd's messages are weird. I haven't looked, but I kinda assume the code is inefficient as using a single message is slower than using a [list prepend ] -- [list trim ] combo.

This bears repeating because it is the opposite of what you would probably intuit.

Messages are slower than the list objects.

This might change, as the list objects are new compared to messages, but the code for messages probably has to sanitize a lot more inputs than the list objects...
Also fyi, the prepend and append objects are part of the cyclone library and are not part of vanilla.

The reason why you would use the list objects rather than messages really just comes down to pd's semi-explicit typing. Some objects need to know what kind of input is coming so they need a selector like list, symbol, float, set, etc. Other objects just interpret whats coming at them so they don't need a selector.

I never had to install anything on mac to get vanilla to work. I may have installed xquartz when I installed mac's devtools, but I'm pretty sure I already had pd downloaded at that point. The only thing about mac that sucks is that tcl/tk (the stuff used to make pd's interface) is usually version 8.4.

That should make zero difference to the sound though.

[loadbang ] -- [; pd dsp 1 (

^ If you want to make it a no brainer for him.

edit: since I mentioned tk, might as well point out that you can download a version of pd with tk 8.6 built into it. Having trouble finding the link atm, but its on the forum here somewhere. Danomatika's distributing it.

Here is a control rate lfo I had in one of my patches.

I just used my oscillators' waveforms.

If you aren't actually storing some waveforms, then using a [sin] object would be the way to go. ...Basically just a choice between ram and cpu.

If you are switching the tabread between multiple arrays, then you need to control where the start and end points of the read will be.

In the pic above, the tabread goes from -1 to 1 and back by skipping the first and last quarter of the sine wave's cycle. Use two [sel ] and [f ] objects if you need to change those indices.

@wqt you have to be careful overwriting this proc we are playing with, because if anything goes wrong in the beginning, pd's gui doesn't get connected to pd's internal process.

The second plugin was an attempt to expose tcl procs to the print object. This is potentially really nifty, thanks for having this problem. Anyways, the way the second plugin works is that you have to send a name to a print object named set_receive. From then on, any print message will be sent to that receive. Print after having deleted that object and you could start an infinite loop.

The if statement if {$pdwindow::receive_name ne ""} should keep an infinite loop from happening while the receive exists, or before it has been initialized, So I'm not sure whats happening. Need more info.. hmm.

@whale-av Maybe it was because I didn't add the whole code..

Well, when I printed the message arg from logpost into the console (not the pdwindow) I found that it doesn't print the entirety of the message in one function call.
So you can't rely on any index of the message arg past 1 being what you expect...

variable pdwindow::receive_name {}

set lp_args [info args pdwindow::logpost]
set lp_body [info body pdwindow::logpost]

append lp_body {
    # find 'function' names
    puts msg:\ [llength $message]\n$message\n

    if {[lindex $message 0] eq "set_receive:"} {
        set pdwindow::receive_name [lindex $message 1]
        return
    }
    if {$pdwindow::receive_name ne ""} {
        #this is the part where you send a tcl message to pd
        pdsend "$pdwindow::receive_name $message"
    }
}

proc pdwindow::logpost $lp_args $lp_body

This works for me, and it doesn't produce an infinite loop if pdsend posts an error. Try it out.

EDIT:: remember to get rid of that puts statement. I forgot to.

@whale-av you're right. That is dangerous. Hmm.. I tried catching it, but pdsend probably already catches the error so, you could add a break statement to filter out that particular error message maybe...

Well, instead of creating a canvas dedicated to a receive, I figure that it would be best to make some 'functions' you could send to the pdwindow through print or something.

hmm.

variable pdwindow::receive_name {}

set lp_args [info args pdwindow::logpost] 
set lp_body [info body pdwindow::logpost]

append lp_body {
    # find 'function' names
    if {[lindex $message 1] eq "set_receive"} {
        set pdwindow::receive_name [lindex $message 2]
        return
    }
    if {$pdwindow::receive_name ne ""} {    
        #this is the part where you send a tcl message to pd
        pdsend "$pdwindow::receive_name $message"
    }
}

So maybe this will work. It doesn't explicitly check to see if the object exists, which could be dangerous if you deleted the object. It does allow you to set the receive name though. Just send a [set_receive receive_name( message to print.

Well, if it were me, I'd make a gui plugin. The proc that underlies everything that gets posted to the pdwindow is
pdwindow::logpost
So use introspection to overwrite it.

set lp_args [info args pdwindow::logpost] 
set lp_body [info body pdwindow::logpost]
#this is the part where you send a tcl message to pd
append lp_body {
     pdsend "receive_name $message"
}

#then actually overwrite it.
proc pdwindow::logpost $lp_args $lp_body

So replace receive_name with whatever name you'd like to use. Hopefully this will work with externals, i tried it with print. You'll have to route out other messages posted to the window.

If you have to use a unique identifier ($0) in the receive name, then.. I'll have to think about that..

Just wanted to say thanks