• NoDSP

    @Roomy You might want to bring your class instructor up to speed as to the current state of Pd Extended. Doesn't seem right to expect students to rely on a piece of old dead software to complete their work. We've seen more than a few issues on here with Extended and newer operating systems.

    posted in technical issues read more
  • NoDSP

    I don't know if this helps (depends on what you are doing), but one reason I haven't had much use for [pd~] yet is because I usually just run multiple instances of PureData when I need different startup variables. The main issue you might have as using this method as a workaround for your problem is setting up the needed communication between the two instances.

    posted in technical issues read more
  • NoDSP

    It appears to be DSP-centric oversight or some unfinished functionality at work here. I noticed it is possible to go into the sub-process media menu and manually create midi ports for the sub-process after it is started, but as you say -- no way to do it with the sub-process startup flags.

    posted in technical issues read more
  • NoDSP

    @RolandTpd Definitely the wrong place to post this. You should probably start a new thread in the technical issues section of the forum. Use the New Topic button above the first post on the list.

    https://forum.pdpatchrepo.info/recent

    AV Linux is a totally separate Debian based distribution that has nothing to do with Ubunttu -- on purpose.

    http://www.bandshed.net/avlinux/

    http://distrowatch.com/table.php?distribution=avlinux

    This thread is already rather dated: AV linux has a new 2017 version (there was also some word they going to move to J2).

    posted in technical issues read more
  • NoDSP

    I'll let someone else chime in with specific Pd patch examples, but the central objects to any patch that does this would be the [ftom] (control) and [ftom~] (DSP audio signal) objects. You can read the Pd help files on those to give yourself a head-start.

    posted in tutorials read more
  • NoDSP

    @jancsika That's not a bad idea in principal -- some of the other linux midi apps give you the option of patching both externally and from a patching routine internal to the app -- but beware. A lot of the time I notice those internal patch routines either don't work properly or cause conflicts/screw-ups with the external patch apps in situations where you find you have to use both. I don't know if it's because of improper coding of the internal patch routines or a limitation of the Alsa midi system, but It's for that reason I always use the external option with all my linux midi apps.

    I'm just trying to say that all the midi patching stuff may be more complicated than it seems on the surface. The Mac and Windows Pd Vanilla midi dialogues are supposed to work that way but I can tell you they are definitely broken; not just because of the limited 9 port access (it's currently 4 in L2ork?) but because something isn't right (or completely absent) in the whole port multiplexing scheme. I've never been able to connect those 9 ports past the first 9 midi ports on the Mac's system list. You can test this with any application that will create virtual midi ports, network midi ports etc.

    posted in technical issues read more
  • NoDSP

    @NoDSP said:

    I know they tried implementing something like that in Pd some time ago...

    Just for reference, here's the Pd list thread I was referring to:

    https://lists.puredata.info/pipermail/pd-list/2012-10/098642.html

    posted in technical issues read more
  • NoDSP

    @jancsika said:

    I don't think anyone is asking for auto-patching.

    Well, the OP was asking for a "plug and play" option, which I would take as auto-patching a connected midi device to the first available input in Pd.

    posted in technical issues read more
  • NoDSP

    Well, sort of.

    You can use the 'greater than" operator in combination with a route object to do a basic absolute-to-binary conversion, like so:

    absolute-to-binary1.pd

    You may want to add a line object in there to smooth things out in case of value jumps from the encoder or you'll start to lose range -- but that brings us to the second problem. That is, how much range do you need for your "endless" value? If you only need 128 steps, you're all set. If you need more than that (or less) you need to do a bit more work.

    If the 0-127 encoder wraps back to 0 after you exceed 127 and back to 127 when you go below zero, that would be one problem. However, most I have seen have a "stop" at the max or min value no matter how far you turn them. You might try adding a second route object in that case:

    absolute-to-binary2.pd

    Anyway that's a start...

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!