The [metro 200] is actually not supposed to be there, it was for a different method I was trying out for a bit but did not fully delete.
Ahhh ok! I guess I am still confused about what exactly a block cycle is and what it is for. I think I was assuming that metro~ outputs a bang for each sample, not for each block cycle.
I know that reducing the sample rate will make it less bright as it reduces high frequency content, but I was trying to make the default setting of this patch basically indiscernible from white noise, so that it only gets less bright when you hit the message boxes other than 1.
Thanks for your help, I will try changing block size.

Hi,
Basically, [counter] is effectively reducing the sample rate: metro~ sends out a bang 44,100 times per second, clocking the rate at which [random] produces a new number. [Counter] turns this rate to 1/2 the amount of bangs/second, 1/3 the amount, etc. so that the random signal (noise) will be half the frequency, a third, and so forth.
I will try your patch later, as I am not in a spot where I can test out your patch right now. However, by looking at it, it is not doing what I am trying to do (generate a noise signal that can be modified from it original generation), as it already begins with a [noise~] object.
Thanks!

Hello,
I am trying to make a patch that defaults to making white noise, but can be altered to make pitched divisions based on the sample rate. Basically, I am using metro~ to bang a random object at the sample rate to make the brightest version of the noise, which should be banging at 44.1khz. But it does not seem to be banging this fast, because the initial noise sound is not very bright at all, and already sounds quite 'digitized'. I have attached the patch so far. Any ideas on how to make the initial sound basically identical to white noise?
digital_noise_1.pd

I just made a super simple patch with TuioClient to allow Reactivision to control various parameters.
However, when I quit pd and reopen the patch, the patch does not load, and I get a watch symbol (on a mac, indicating there is a stall). The stall goes on for an indefinite amount of time (it has reached 45 minutes at one point).

There is another strange behavior, which allows it to work in a compromising way: when I let it keep loading, but switch to another window that is not pd (such as chrome), and then switch back into pd, the watch is no longer there, but the patch is not loaded still. But then, if I open the same file (or any other file with TuioClient), it loads with no problem, and works alright. However, it acts as though the file has loaded twice. My evidence is that in the original file, I had an outlet of TuioClient going to a [print]. In the loaded version of the file, I disconnected all [print] objects, and yet updating data from the TuioClient was still printing.

How do I solve this issue?

Here is what the console reads:
(Tcl) INVALID COMMAND NAME: invalid command name "listening"
while executing
"listening to TUIO messages on UDP port 3333"
("uplevel" body line 1)
invoked from within
"uplevel #0 $cmds_from_pd"

I have tried opening ReacTIVision both before and after opening the patch. I have a MacBook Pro, version 10.6.8, with 2.4 GHz Intel Core. Thanks.

@Load074 said:

I've had similar problems with my old PPC-based Mac. I don't remember exactly what my problems were, or how I solved them, but it involved deleting some files from the "Library" folder.

I'd say, be prepared to do a fresh installation (although I didn't need to), and try some variation of the suggestions here:

http://forum.pdpatchrepo.info/topic/6053/about-problem-with-pd-on-mac-os-lion/3

(I THINK this is what I did... delete the org.puredata files in the Library folder. And I think the problem started when I was re-configuring either my audio or MIDI settings.)

Thanks, this was successful! All works as it should now.

@LandonPD: For future reference how would I let it 'uninstall itself'?

Hi, ever since I messed with the audio preferences last night pd-extended has literally not been starting up. I have a MacBook Pro version 10.6.8 Intel Core, and use Pd-extended version 0.43.4. I also have version 0.42.5, which works as normal.

All I did was experiment with changing the block size, I think from 256 to 128, which did not make a noticeable difference, and then to 1024. Once I did this, pd froze up, so I force quit.

I tried reopening, but the icon bounced as if it was about to open, and then simply stopped bouncing. In Activity Monitor, it said that Pd-extended is not responding, and is using up I think 0% of CPU, but below that it shows simply 'pd', which was using up between ~90-103%! I manually quit these processes (which may have been the wrong move). I restarted my computer, and tried it all again the same, and got the same result. I tried deleting pd-extended by trashing it and emptying trash, then reinstalled. The reinstalled version still did the same thing.

What should I do? Thanks in advance.

I have a couple of patches that use the [TuioClient] to connect to reacTIVision. However, after closing and re-opening Pd, I get this when I try to open the patches:

(Tcl) INVALID COMMAND NAME: invalid command name "listening"
while executing
"listening to TUIO messages on UDP port 3333"
("uplevel" body line 184)
invoked from within
"uplevel #0 $cmds_from_pd"

This is accompanied with a stopwatch symbol, which lasts a few minutes, and when it goes away the patch still does not load.
I am then actually able to open the patch if i do so from the Finder rather than the Open in the Pd menu, but sometimes it does not let me edit the patch.

Can someone please help me make it work consistently? Thanx.

EDIT: patch uploaded.

http://www.pdpatchrepo.info/hurleur/DARK_JAZZOR_6-23.pd

Here is one of my first serious projects with PD-extended. As the title of the file indicates, it was made to sequence ReDrum in Reason (even though that already has a very capable sequencer), but it will work for any drum machine that uses MIDI notes 36-45.

There is a flamming device that will send out delayed, lower velocity copies of each hit in which it is engaged. You can simply turn on flam or off, or you can designate which steps you want it for by engaging 'FLAM_AUTOMATE' and switching on the desired steps at the bottom.

Enjoy!

http://www.pdpatchrepo.info/hurleur/REDRUM_DELSEQ.zip

Just uploaded the patch, is now visible in the original post.

I don't think it's broken, because I am sometimes able to get it to work but it is unpredictable when it will or will not. Also, even when it works, sometimes the GUI does not, or the GUI stops being responsive in weird ways after a few minutes...

update: just downloaded version 0.42.5, moved the prefs from ~/library/preferences into a different folder, and it seems to work fine. However, I really want it to work in the version I normally use (0.43.4). Any advice?