• NothanUmber

    @bocanegra: Sounds promising! How did you get it to run on Windows with Purr Data? Were you able to compile (or even download from somewhere) a 64 bit version of Purr Data? Or did you compile a 32 bit version of faustgen~? Or was it with vanilla Pure Data and not Purr Data (that's what works for me, too)
    Edit: Ah, you were probably not answering to my quest to get faustgen~ running but to the OP about Purr Data in general. (Unfortunately I don't have an answer to your question, was only testing on Windows)

    posted in news read more
  • NothanUmber

    Ok, got the light version of Purr Data to compile on Windows 64 bit with a few changes to the Makefiles. But the application crashes on start with error code "0xc0000007b" (even without any faustgen~ externals copied over).
    Are there known incompatibilites with Win64? For Pure Data vanilla a 64 bit version exists (with that the faustgen~ from Deken runs out of the box). Will probably go with vanilla then for the timebeing.

    posted in news read more
  • NothanUmber

    Thanks for the hints!
    Currently the plugin is 64 bit by default, and Purr Data only available as 32 bit version for Windows.
    So I probably have to compile (at least one of) both anyways.
    Will try to get Purr Data compiled for Win64 as a first step.

    posted in news read more
  • NothanUmber

    Thanks, Purr-Data is great! Particularly menus work a lot better on high-DPI screens (the only way I found to work around this for Vanilla was to reduce the screen resolution..)

    Is it possible to download non-UI related externals like faustgen~ from a PD Vanilla installation and just copy them over to Purr Data? Or would I have to recompile? Or is Purr Data too far away from Vanilla, so the source code of a Vanilla external first would have to be adapted to be usable?

    posted in news read more
  • NothanUmber

    Hi everybody!

    Getting my feet wet with Pure Data on the quest to find an environment that works well for interactive modular synth stuff with MPE compatible controllers.
    On first sight I am quite impressed - particularly the "clone" object is really a relevation when it comes to managing several voices (compared to most other eurorack-style mono-voice-module modulars)!

    Two questions:
    Do we always have to create an abstraction (= a new file) when we want to clone something?
    Have some cases where the cloned objects are so highly special that they only make sense within one particular parent patch and even there they occur only once. (E.g. have an "mpein" object for reading mpe midi data that uses a 16 times cloned, quite specialized mpein_channeltovoice" abstraction internally)
    Can I somehow use a subpatch instead of an abstraction that is stored together with the main patch file?
    (Not a big deal, might just be more convenient when sharing stuff to have one file instead of a bunch of them)

    And assuming I have a synth with quite demanding calculations per voice - would it be possible to somehow combine pd~ and clone? E.g. to run 16 instances of an abstraction in parallel on 4 cores with four voices each?
    (Also not a big thing if it doesn't work, I can always manually create 4 pd~ instances with "clone myvoiceabstraction 4" inside each. Would be convenient though not having to copy everything N times. Is still ok for 4 cores, but not so much fun for a 32 cores 64 threads CPU :) .)

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!