warning: I'm super fresh out of the garden.. so every question i ask here is bound to be dull....

i've now tried pulling together three separate projects / patches with pd extended; with a logitech mic input and with arduino's diecimila microcontroller. two involved pulling up sample files but after two weeks of hair-pulling i still couldn't output any sound. so now i've opted for arduino's controller (the same as above) and a proximity/infrared sensor with a pd patch selecting input integers that are attached to gui bangs, intended to generate pretty much any sound i possibly can. still no sound via my labtop. taboot, pd keeps freezing up entirely.

i've scoured the internet, the help-files (many of which do not seem to work), downloaded the program three times, reset the preferences several times over, and fiddled with my computer sound pref's as many times.... someone please oh i'd be ever so grateful if you've any advice as to what the heck i'm missing here? : )

i have the latest version of pd-ext for osx, i'm using osx 10.5.6 on a MacBookPro; i've no prior programming nor linux skills (the terminal is a mostly-mysterious thing to me).

advice, insight, comments, questions?

most obvious first question:

do you have DSP turned on ? there is a button on the pd console for it, or you can put it in a patch like this:

[loadbang]
|
[;
pd dsp 1(

I have a toggle cabled to the dsp, but if i use it, the program crashes. instead, i have been using the apple command key + "/". in which case it may still freeze up. is the loadbang particularly necessary? i have the impression there is just too much going on at once (input from arduino / device comport, multiple bangs, arrays/tables, et al) - but i've seen much crazier patches. it could perhaps relate to data rates/sizes? i haven't a grip on any of that yet...

at anyrate... would any of this effect whether or not i get sound/output?

loadbang actually does seem to help, in terms of the program not freezing up... so the rest is seemingly all about my heywire programming (still no sound/output)..

i now have sound output if not using the sensor or arduino (which is half my purpose). so i've narrowed my challenge to one that i would think is fairly simple: use a gui bang to trigger osc~... i've tried chaining together various messages and / or objects between the bang and the osc~, but to no avail. so it seems this describes part of my programming problem...

suggestions?

you could post the patch here if advice doesn't help... just attach it to a reply.

but, my response at the moment is: right click (or mac equivalent) on objects to read their help files. that way, you would see, for example, that [osc~] needs a float (numerical) input, not a bang.

I abandoned ship and stuck instead with generating notes - but now I'm back to figuring out how to manipulate various inputs from the microphone. It is a USB Logitech headset mic (fyi). At present, I can achieve my aims if I don't care to complicate things.. but I definitely intend to complicate things. So where I'm stuck at present is in terms of subpatches triggering my delays, I'm trying to do so via a bang on the parent patch (I have the basics in there [inlet] / [throw]) and can get the subpatch working if it isn't a subpatch wtihin a parent patch. adc~ seems to be the wrong way to transmit signals in and out of patch.. yes? As noted above osc~ hasn't worked for me either, nor has line~ or switch~.. Though I can't be sure I've used either of the latter correctly in those tests. The subpatch is attached....

http://www.pdpatchrepo.info/hurleur/paroleLive2.pd

Oh yes - and you'll notice that this last try I was playing with spigot~.. but get an error stating ": adc~: no method for 'float'" and I can't read any audio of this patch yet at all.

thanx, in advance, for any insight....

I figure I should attach parent patch too, just in case it's needed (to understand what I am up to)...

http://www.pdpatchrepo.info/hurleur/paroleTrial3.pd

try removing the gui objects in the parent patch. all those [moses] objects connected to visual bangs, if you replace the bangs with [bang( messages how does it go? in general pd's gui is very slow, and if they are being triggered constantly at audio rate or something, that's going to be really intense, and cause your system to freeze.

First off, the micSensor argument you've given to [adc~] doesn't mean anything. [adc~] accepts numerical arguments corresponding to you're audio inlets, so you'll want to specify that.

I'm not entirely sure exactly what you're trying to do, but I think you're trying to turn off audio coming out of the [adc~] object. I don't actually know what the inlet to [adc~] does in Pd (in Max, a toggle, like you have, turns dsp on and off, but as you've illustrated, Pd doesn't like that). Instead, feed the [adc~] outlet to the left inlet of [*~] and feed the toggle into the right inlet. Connect the outlet to that to you're weird delay setup. The output of you're sample2 table will keep playing, though, and I don't know if that's what you intend or not, but you can, of course, connect the toggle to that as well.

Also, [r spigot 1] should probably be [r spigot1]. Second arguments are ignored by [send] and [receive], so [r spigot 1] and [r spigot 2] would be the same thing.