• oid

    @whale-av They are serial with signal branching off between so were probably playing with phase, possibly a yet implemented/sorted out or dropped feature. But my explanation was mostly a joke and not the sort of joke which will carry well over the internet with its very broad and global demographic. I was reliving the experience of making the first abstraction that I shared, I wish it was as clean as @izecake's, I seem to have gone out of my way to obfuscate the useless operations it contained.

    posted in abstract~ read more
  • oid

    @dreamer They are clearly vestigial from when the abstraction's logic was being sorted out and were probably deleted and brought back many times and their deletion or addition often breaking the abstraction for some incomprehensible reason; they served no purpose and you stared at the before and after for an embarrassing amount of time trying to figure out why it works with such a useless operation that does nothing until you finally see the obvious and delete them once and for all. Then you realize you actually needed a [* 0.5] there, so you put it back and nothing works even though a [* 0.5] should not break anything, just decrease volume or something, but nothing works. Back to staring for an embarrassing amount of time. Delete them, still doesn't work. Put them back and make them [* 1], works. More staring. Learn not to tempt providence and call it good enough. Finally realize what is going on and fix the actual problem but really don't want to tempt providence, just want to make music, so leave them. Isn't this the standard pd work flow? I have at least one [* 1] or [+ 0] or the like in most of my patches.

    posted in abstract~ read more
  • oid

    @izecake Fun stuff, I still have my old DD-3 delay sitting about for doing this the old fashioned way. Couple notes, add a $0 to you delay names so you can have multiple instances of abstraction in use without multiply defined errors, [delread~ $0glitch 50] and [delwrite~ $0glitch 500] or the like. Once you do that your [print] is going to irritate you, nice information but every instance of the abstraction is going to print it and spam the log when you load that patch with 83 instances of your abstraction. Make it a comment so people can open the abstraction and instantly know what it is even if they don't have the help file.

    posted in abstract~ read more
  • oid

    @atux I would open up the help browser and start learning data structures, this is a perfect use for them an a good beginner project to learn with. The data structures section help patches have gotten to be good enough that there is no longer a reason to fear and avoid data structures.

    posted in technical issues read more
  • oid

    @whale-av But menubar would be gone, perhaps that part did work and he forgot to mention that? I think you would be hardpressed to find a wm which does not honor the full screen attribute these days other than some tiling wms. I did just remember wayland which debian seems to use by default but xwayland should properly handle the X stuff if I understand how it works correctly. This might be worth a bug report but I am not sure where that bug report should be made or how to figure that out.

    Running a non-wayland wm might be an solution, but this might require switching to X as well or xwayland my handle it and solve the issue. I don't know wayland well enough to offer anything but guesses.

    posted in technical issues read more
  • oid

    @whale-av I don't think kiosk-plugin uses wm attributes other than full screen and the title, the rest is pure tcl/tk? Or am I missing something? I am just starting to not be completely confused by tcl/tk so am still confused fairly often. I tested kiosk-plugin on a few different wm all of the quirky nonstandard sort which often lack in the things it is generally assumed a wm will support, the only issues I had was in tiling wms full screen does not quite work but it often doesn't in tiling wms since they are doing their best to force everything into the tile.

    posted in technical issues read more
  • oid

    @atux It is easy to get fixated on [list store] with all of its features, some things are easier to do with the other list objects.
    listget.pd Untitled.png

    posted in technical issues read more
  • oid

    @atux From what I could tell ofelia will not play well with newer version of libglew than it was compiled against so you need to compile ofelia yourself. I never actually got ofelia to work but I use a linux distro which openframeworks does not have a build script for and had to spend a night chasing compiler errors and all sorts of fun stuff so my issues may have been completely openframeworks whose community was not exactly helpful. Here is the thread I made, it might have some clues for you if building ofelia does not work for you https://forum.pdpatchrepo.info/topic/13794/troubles-getting-ofelia-to-work. If memory serves ofelia was an easy and straight forward build with no drama, about as simple as pd.

    posted in pixel# read more
  • oid

    @seb-harmonik.ar I just went with bind all <BackSpace> {::pd_bindings::sendkey %W 1 7 "" 1 7} and turned the backspace into an ascii bell which makes everything work and should not cause issues. Weirdly still get the KeyRelease event for BackSpace instead of Bel but nothing gets deleted and everything works with just a change of an 8 to a 7 in my patch.

    posted in technical issues read more
  • oid

    @seb-harmonik.ar said:

    tcl being tcl, but from discussions seems like it shouldn't have to be..

    Perhaps this has something to do with the KeyUp and KeyRelease bindings going to sendkey which sends all KeyUp and KeyDown events to sendkey? Key codes 8 and 127 are essentially bound twice on linux and sendkey is left to figure it out.

    While this works it did create an unforeseen hiccup, [key] and [keyname] no longer get these keys because sendkey, but [receivecanvas] still gets them but only the release which is slightly irksome but not a huge deal

    Edit: Yup, it is the generic bindings for all KeyPress and KeyRelease events which were the issue, it seems without something (even whitespace) to bind too it will not unbind those, if you do bind all {} for KeyPress-Delete, KeyRelease-Delete and Delete it works.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!