• jancsika

    Ok, all those issues should now be solved. I just need to test on Windows first.

    The only thing I didn't include was allowing the menu to display outside of the parent window. That would require a "native"-looking widget on each platform, and then the height, width, and styling wouldn't be consistent across platforms. (Also, I'd have to manually disable the widget in edit mode-- otherwise it would behave inconsistently to all the iemgui widgets and other stuff.)

    posted in technical issues read more
  • jancsika

    @jukkapoika

    [bng]
    |
    [symbol const]
    |
    [pack s 0]
    |
    [route list]
    |
    [send $0-array]
    

    posted in technical issues read more
  • jancsika

    Does it have [list]?

    If it does, here is a helpful pattern for sending messages:

    [bng]
    |
    [list const 0]
    |
    [list trim]
    |
    [send $0-array]
    
    

    posted in technical issues read more
  • jancsika

    @sensn Btw-- which OS?

    posted in technical issues read more
  • jancsika

    @sensn Thanks for the info. Most of these should be pretty easy to fix.

    posted in technical issues read more
  • jancsika

    @danothedino You should be able to use [netreceive], [netsend], and the osc objects I mentioned above.

    posted in technical issues read more
  • jancsika

    It's probably because of the line in glist_delete from g_graph.c that redraws all the scalars on every visible canvas when you delete any object like [drawpolygon] or [drawcurve].

    Closing a patch triggers the deletion of every individual Pd object, including [drawpolygon], [drawcurve], etc. So for each one of those drawing instructions you have in your patch, Pd will send another message to redraw every single scalar.

    posted in technical issues read more
  • jancsika

    I'm also curious about what triggers the Stack Overflow.

    A safety mechanism that puts an upper limit on how deep an immediate "chain reaction" can be in response to an event like a mouse click, key press, netreceive, or clock callback (.e.,g. a bang coming from [delay 1000]). When I say "chain reaction", I mean an initial message to an object triggers an outgoing message to another object, and so on until there are no more outgoing messages to process. When I say "immediate", I mean the messages get sent without any logical time in between.

    Here's an example:

    [bng]
    |
    [bng]
    |
    [bng]
    

    If you clicked the object chain above, you get an immediate chain reaction 3 objects deep.

    Now, if you extended that chain so that there were 1001 [bng] objects-- each with a single connection to the next-- you'd get a stack overflow error because it exceeds the limit Pd puts on how deeply a single message is allowed to flow in an immediate chain reaction.

    The way Pd is coded, these simple examples actually end up using recursive function calls in C. Using recursion with too many levels can end up overflowing the stack and cause a crash, which is why you get that particular error message. (1000 may be too small a number nowadays, but recursion is complex and I'm not sure how one would come up with a better number.)

    When you use recursion explicitly in a Pd diagram-- that is, hooking an object's outlet to an inlet that is back up the chain-- you make it way more likely to hit this particular error. You can imagine that your recursive diagram ends up "unrolling". That is, if you have a chain of 4 objects where the bottom one connects back into the top one and recursing 251 times, you're going to hit a stack limit and get the error.

    The [until] object solves this "explicit" recursion problem-- it sends a bang to its outlet, and when the resulting immediate chain reaction has finished it sends another until the specified limit is reached.

    So if you have this:

    [10000(
    |
    [until]
    |
    [bng]
    |
    [bng]
    |
    [bng]
    

    You go two objects deep for the bang coming out of [until], then three more for the first time through the chain of [bng] objects. So now we're 5 deep. But once the first iteration of the [bng] objects are done they unroll, so we're back to being just 2 levels deep. Then the [until] object starts its next iteration, which goes 3 more deep, then unrolls. It can do this indefinitely, which is why [until] is preferred over using recursive object chains in Pd.

    posted in technical issues read more
  • jancsika

    @whale-av said:

    @jancsika I would not know how, and maybe the readme is an old one copied over?
    There are other files in the download that are specific osx though........

    Those are most likely for building Gem as a 32-bit library.

    The constraints for including Gem in the OSX version of Purr Data are the following:

    • all Gem dependencies must be met with Homebrew's brew install command.
    • must be built as a 64-bit library
    • no special Purr Data-specific hot-patching, just simple build instructions (possibly including configure flags)

    If anybody gives me instructions on how to build Gem within those constraints under OSX, I'll make the necessary changes to include Gem on OSX for the next Purr Data release.

    posted in technical issues read more
  • jancsika

    Looks like a stack overflow from sending the bang back into the inlet of [textfile].

    If you instead use an iterative loop there with [until] you won't hit the overflow.

    posted in technical issues read more
  • jancsika

    @Octopoulpe What error are you getting?

    posted in technical issues read more
  • jancsika

    @whale-av said:

    @danothedino @jancsika I have 0.94-test3 gem working with 64-bit Pd 0.47 on windows. The source code is available here....... https://github.com/avilleret/Gem/releases/
    Could that version be compiled against Purr Data on OSX?....... no idea. The readme suggests the possibility.
    David.

    What in the README suggests that? I see nothing specific regarding compiling Gem as a 64-bit library under OSX.

    posted in technical issues read more
  • jancsika

    What does "datas" refer to in this case?

    posted in technical issues read more
  • jancsika

    I guess [osc] is also not supported yet?

    There is [oscparse] and [oscformat] if that's what you're referring to?

    Are there any other ways to get video manipulation with 64 bit osx and purr data?

    Unfortunately, no.

    posted in technical issues read more
  • jancsika

    Unfortunately Gem doesn't build with the 64-bit OSX Purr Data binary.

    I don't currently include the externals in the search index. I'll do that in a future release, which will allow you to type "knob" as the search term and find the relevant object. (I'm also considering just adding "knob" as an automatically loaded object to make all this easier.)

    Do keep in mind that audio GUI apps are about the only ones that use "knob" widgets. Physical knobs are great because of the control you have with your thumb and forefinger (plus tennis muscle efficiency for large turns). Using a mouse to control a digital knob is like trying to use a physical knob with chopsticks.

    posted in technical issues read more
  • jancsika

    @emviveros Thanks.

    So it appears to have the exact same default range as [moonlib/mknob], meaning it should work as a drop-in replacement. (Another place to check is the object args.)

    posted in technical issues read more
  • jancsika

    @Michael-Z-Freeman

    The main question is whether "mknob" and "knob" output values in the same range.

    Could someone test [knob] for me and say what the default range is? It looks to be 0-1 from the code but I'm not sure.

    posted in technical issues read more
  • jancsika

    EDIT: Probably a bit beyond my pd experience here, but I tried replacing "knob" with "mknob" just for the volume control.

    Oops, sorry... try [moonlib/mknob]

    posted in technical issues read more
  • jancsika

    @Michael-Z-Freeman Would you mind checking if moonlib/mknob is a suitable drop-in replacement for flatgui/knob? Judging from the code the interfaces look very similar.

    posted in technical issues read more
  • jancsika

    I believe I ported [mknob] but not anything from flatgui.

    I'll see what kind of work is involved in porting [knob].

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!