• Monetus

    @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.

    posted in technical issues read more
  • Monetus

    @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
    

    Screen Shot 2017-02-12 at 12.58.12 PM.png

    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.

    posted in technical issues read more
  • Monetus

    @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.

    posted in technical issues read more
  • Monetus

    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..

    posted in technical issues read more
  • Monetus

    Just wanted to say thanks

    posted in news read more
  • Monetus

    I used an array of symbols in a struct with a drawnumber object to make a symbol slider. If you wanted to avoid the structs, you could indeed use a vslider underneath a canvas to feed indices into a [text get] object.

    To make the menu actually popup, you'd have to create an object with a tcl/tk plugin, or make an external.

    I played with the idea of making a popup menu in the tcl/tk objects, but I was making an autocomplete plugin, and settled on just drawing into the canvas itself. Lots of cool things you can do with plugins or structs.

    posted in technical issues read more
  • Monetus

    Screen Shot 2017-01-12 at 11.13.01 AM.png

    Trigger has type casting.

    posted in technical issues read more
  • Monetus

    Sorry its taken me so long, I've been without internet.

    hotkey-plugin.tcl

    I went ahead and created a plugin for you. It has a bunch of comments and guides through the code. Please post if you don't understand anything, its not as direct as your code.

    I'm going to make a gui to edit ALL hotkeys and add new ones, but I hadn't worked every part out yet.

    I'll post when I do.

    posted in technical issues read more
  • Monetus

    so, the way you have used the bind command is perfectly fine, I was only suggesting a proc if you wanted to be able to toggle the hotkeys back and forth while pd is running.

    And yes, you can use tcl to send pd messages and create objects. For the gui objects, the menu_send and menu_send_float commands are all you need to make sure bind is triggering. If you wanted to make specific objects or abstractions be bound to a hotkey, you need to create the obj then trick pd into thinking you typed something in. You do this with the pdsend command.

     pdsend "$mytoplevel key 1 $keynum 0"
    

    look at my github, the rename_obj proc. also look at the embedded button bar plugin buried in the pdsite.

    posted in technical issues read more
  • Monetus

    There are a million ways to learn programming, and I have yet to be convinced there is a best way. Libpd currently has an API for C, Java, Objective-C, C++, Python, and C#. Definitely read the wiki on libpd's github.

    Since you mentioned making plugins, I'd look into which languages the particular development kits use. Then I'd go over to r/learnprogramming on reddit to read some of their resources and ask around. Download some ebooks about the language you want to learn too. O'reilly media usually has a bunch for free.

    There is a difference between knowing the syntax/paradigms of a language and actually knowing how to use it, so definitely try to do things as you learn.

    I'd suggest C++, but thats just me.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!