• beep.beep

    @taylorrandall Welcome to Pd!

    Yes, this is a very common area of confusion for new users. Your [&&] object needs to receive the new value from [!= 25] in its right inlet before it gets the value from [!= 24] in its left (hot) inlet, which is what outputs the final result at the bottom. Use the [trigger] object to control the execution order:

    triggerexample.jpg
    trigger.pd

    Takes a minute to get the hang of this, but you'll need to use triggers all the time to ensure that object boxes receive values in the correct order. Check out 2.3.3. hot and cold inlets and right to left outlet order (scroll about 25% down the page)

    posted in technical issues read more
  • beep.beep

    Finally got a chance to try your newest .so file in my Gem folder. It works! Many thanks for uploading it. I get that tcl error too, but it doesn't seem to cause problems.

    posted in extra~ read more
  • beep.beep

    I tried dropping your posted version of Gem into my Library/pd directory (without modifications) and got "Gem: can't load library".

    But I was able to see that your gem_videoVLC.so is indeed linked to the VLC.app dylib (I think I'm not using install_name_tool correctly in my attempts). I tried copying your .so file to my Gem compilation, and got as far as this:

    [pix_video]: backend #0='vlc'   <--- DISABLED
    [pix_video]: no video backends found!
    

    Incidentally, that vlc-videoplugin.pd looks more like an abstraction than a help file... I'm using pix_video-help.pd for testing. From what I've read, sounds like the message [device screen://( to pix_video should start the webcam if the backend is working.

    posted in extra~ read more
  • beep.beep

    Coincidentally, I've been working on the same thing myself for the past several days. I succeeded in compiling Gem on OSX 10.12 with Pd 0.47.1 (64 bit), using an amalgam of these instructions:

    Gem github wiki

    GEM-dev mailing list

    As seb noted, no quicktime film/video support, and I also get the extra dock icon & Pd crashing sometimes when I close my patch.

    Having noticed this conversation the other day, I tried compiling Gem against Purr Data 2.3.1 using the same general method, but didn't get far at all. I didn't save the errors, but got a sense that it'd be much more involved than just adjusting paths to Pd-l2ork/Contents/Resources...

    I haven't tried to compile the gmerlin plugin, but I have the imageJPEG plugin working, and I've spent many hours trying to get videoVLC working. There are several mailing list discussions which suggest that the problem might be with gem_videoVLC.so (perhaps not pointing to libvlc.5.dylib correctly, either needing editing or symlinking?).

    I'm reaching the limits of my meager hacking abilities, but nonetheless it's pretty exciting to have Gem back up & running on 64 bit! I'm happy to join the cause if others are also interested in trying to work out the kinks in enabling the rest of the workaround plugins (gmerlin, videoVLC), and hopefully also find a way to get Gem working on Purr Data.

    posted in extra~ read more
  • beep.beep

    I second the notion that the Focusrite Scarlett line is a good way to go. I have the 18i8, since my setup needs a lot of inputs, but even that one was relatively affordable. Their newer Thunderbolt interfaces look even more enticing (although I'm biased, since I'm a drummer & always seeking lower latency).

    As for Macs: until recently I was running PD on a 2010 iMac and a 2008 Macbook. The former was solid (until the graphics card gave out), the latter still to this day can run my most demanding patch at 70-80% CPU.

    When the iMac died, I decided to upgrade to the new 2016 Macbook Pro (I was right in the middle of several Logic/FCP projects, and didn't want to jump ship to Linux at that precise moment). The new MBP is certainly slick & plenty fast enough for PD, but in terms of bang for your buck, you can get comparable processing speeds for far less money with an older Mac, or (as alexandros points out) a different brand of computer that can run Linux.

    So, my advice would be to not do what I did....

    posted in technical issues read more
  • beep.beep

    @weightless

    Happy to help! Glad to hear it worked for you. I suppose the forum automatically removes special characters like ~ from filenames when they're uploaded... good to know for future reference.

    As alexandros noted (much) earlier in this thread, d_fat is another valid Mac OS format. I see 2 versions of bsaylor available for Mac via "Find externals", perhaps the one you downloaded was a d_fat version? In any case, if it works, it works!

    posted in technical issues read more
  • beep.beep

    @weightless

    Hi there,

    Indeed, if you’ve read the long thread above you know that this was my first time compiling as well, so I can definitely relate to the feeling of flying blind!

    5 months later I can’t quite remember which edits I made to the bsaylor makefile, but I’m pretty sure this one is the final version that ended up working for me:

    Makefile

    If memory serves, I removed all objects other than pvoc~.c and partconv~.c from “SOURCES” (I think because the others were already working in 64 bit?), and also made sure the path pointed to “PD_PATH = /Applications/Pd-0.47-1-64bit.app/Contents/Resources”. Then I ran “make” (with the patched pvoc~.c in the same directory as the makefile, and fftw installed as noted), and got my new pvoc~.pd_darwin file to replace the old (non-64 bit) version in my bsaylor folder.

    It was rather satisfying to successfully compile, but I still can’t say that I understand most of the errors that pop up during the process. It’s also entirely possible I’m forgetting other key steps that I took, as I was beating my head against this for days at the time. If it helps, here’s the darwin file that I got working on 64 bit:

    pvoc~.pd_darwin

    posted in technical issues read more
  • beep.beep

    Excellent! I'm glad to know there are others who have got it working.

    posted in I/O hardware diyread more
  • beep.beep

    Success! My internet has been down for a week, so had to wait until today before I could try installing fftw via Homebrew. I was able to do so without much trouble, and after re-editing the bsaylor makefile & recompiling, the patched version of pvoc~.pd_darwin is up & running properly in 64-bit!

    I really appreciate your help! I wouldn't have known where to begin without your helpful advice.

    Cheers,
    -Jon

    posted in technical issues read more
  • beep.beep

    Thanks for those links to compiling info, much appreciated!

    I think I'm getting closer... I realized that the makefile is pointing to /include because that's where m_pd.h is located in Pd-Extended, but that file is in /src in the vanilla versions I'm using. I tried changing that path, and also tried pointing to a version of Pd-Extended that I have, but now I get this:

    fatal error: 'fftw3.h' file not found
    

    The bsaylor library comes with a /libs folder containing libfftw3.3.dylib and libfftw3f.3.dylib (required for partconv~ and pvoc~). Perhaps the makefile is looking for these libraries when compiling? I don't see a fftw3.h file anywhere in the source code of pd (including extended).

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!