The floss manual is pretty horribly outdated and written with Pd-extended in mind, which has the Pd core objects and a bunch of libraries/add-ons included. Nowadays, you can use Pd vanilla (aka Pd) which just has the core objects but comes with a handy library downloader to get the rest of the stuff included with Pd-ext, or Purr Data which is basically the new Pd-extended. If you choose to go the Pd vanilla route (which it sounds like is already on your machine), I wrote something awhile ago about using libraries with Pd (basically, look up hid in "Find Externals..." in Pd), otherwise just use Purr Data.
You can use an accelerometer, or a move sensor instead of the phone :)
Pd droid party is a library to be able to port pd patches to Android. You can't build apps with PD :)
You can make everything in vanilla, just learn to turn the extended objects you use in vanilla abstractions.
4: You can plug the output of delread into the input of Delwrite, and it will create feedback. WARNING: You absolutely HAVE to put a [* 0.5] object between them, or this will crash your patch and hurt your hears.
5: At first it seemed quite ok the way it was.
And if I may add, you should stop using Extended. It's no longer up to date -for a long time now. If you don't want to use Vanilla and want some extra libraries, I really recommand you use Purr data, which has loads of libraries and an ultra slick and cool feel and look :)
Good luck ! Sorry you don't have loads of answers, this sub's clinically dead.
You could try lowering the block size. I just tried it and couldn't get it to select anything below 64 (the default), but it might be a problem with windows.
From the PD manual (http://puredata.info/docs/manuals/pd/x2.htm) > 2.4.4. switching and blocking You can use the switch~ or block~ objects to turn portions of your audio computation on and off and to control the block size of computation. There may be only one switch~ or block~ object in any window; it acts on the entire window and all of its subwindows, which may still have their own nested switch~/block~ objects. Switch~ and block~ take a block size and an overlap factor as arguments; so for instance, "block~ 1024 4" specifies 1024 sample blocks, overlapped by a factor of 4 relative to the parent window. Switch~ carries a small computational overhead in addition to whatever overhead is associated with changing the block size.
> Larger block sizes than 64 should result in small increases in run-time efficiency. Also, the fft~ and related objects operate on blocks so that setting the block size also sets the number of FFT channels. You may wish to use block sizes smaller than 64 to gain finer resolutions of message/audio interaction, or to reduce "block delay" in feedback algorithms. At the (untested) extreme, setting the block size to one allows you to write your own recursive filters.
Here's the patch that I made. It just uses the [block~] object to specify block size, then uses [bang~] to get bangs after each dsp block. I was testing it by writing to an array.
I tried [switch~] and [block~] but it seems to clamp block size to 64 if you give it a smaller value.
The part about PD handling MIDI / VSTi would be awesome.
Is there a way to run VSTi plugins without using a third party software?
I found [http://puredata.info/community/pdwiki/Vst/](Vst~), but it looks a bit compliated to install
hmm. I think you need to set the sample size and playback speed but im not 100% sure. I'm still very much new to working in PD. (loving it so far though ;) )
Also, yeah the PD documentation isnt too user friendly. I'm considering writing up my own version of it with a proper search function in Sphinx (here is how its used in the Blender documentation: https://www.blender.org/manual/). :)
EDIT. forgot to add screenshot of patch http://i.imgur.com/gd7XVR9.png
So it looks like my skill level is not gonna be adequate to make a lot of progress.
I was using a template from TouchOSC here And managed to get it to do what I wanted with pd-extended, but as I mentioned pd-extended doesn't work with rPi
I'm at a loss as to how the new commands would be used in connection with an an OSC app.
I'm not a dev/programmer at all, just a open up and mess around till it works person
Pd-extended is way out of date. You should switch to the current version of Pd-vanilla, and use the 'Find externals' item on the 'Help' menu to load whatever extra libraries you might need.
um, yeah i think this is the external you are talking about? http://puredata.info/Members/chr15m/software/v0-0extended/purepd/
it's listed as `purepd-v0.0.extended--externals`, deken's search isn't great, if you just click the 'show all' button you should be able to find this in the list (at least that's what i did).
Sorry for the late response, but compiling was surprisingly easy. For anyone wanting to know, I downloaded the tarball from http://puredata.info/downloads, and followed the instructions in the INSTALL.txt. It built perfectly first run. After installing it, I had to install the tk
package that provided the wish
command. I did not have to install additional build dependencies, as I already have a C++ build environment. If you don't, there is a wiki page on it. Note: don't follow the wiki page on building, its instructions differ from the included instructions and do not work.
Without looking into to it at all (as I said i know nothing of python) you can use Processing and use mouseX and mouseY and pipe those values into pd using osc or some other protocol. You'd have to added benefit of being able to make a pretty gui if you needed too as well.
You can use pd's internal messages to dynamically patch. something along the lines of [; pd obj x y myObject( remembering that a pd patch is just a plain text file should give you some ideas as how to dynamically patch.
Once you start getting comfortable with computer programming logic and GEM, you might outgrow it rather quickly.
When that happens, take a look at Processing. It's easy to communicate between the two programs, so usually people do their audio processing in Pd and their visual processing in Processing.
If you just need 8 buttons and 8 knobs... ;)
I assume you meant build your own hardware though.
I've interfaced with an arduino for inputs and outputs in the past using the serial components in the comport library. Marginally more complicated than midi or osc communication because you have to manually tell pd e.g. which slider is sending the data as well as the data itself.
You can set up some microcontrollers to be recognized directly as usb-midi devices, I know the teensy is one of those, though I haven't used it myself.
Edit: Depending on how many knobs/slider you want, you'll also need this or similar to increase your analog inputs:
https://www.adafruit.com/product/856