[PD] how to send named commands/arguments to an abstraction?

2008-11-22 Thread Rua Haszard Morris
I am having fun making an abstraction. I want it to be able to respond to 
"messages"/commands in a similar way to externals. For example, imagine an 
abstraction that has 1 inlet, and if it gets (from the parent patch) "file 
filename.mid" then it reads that file, or if it gets "bpm 120" it sets the bpm 
to 120, or if it gets "loop 0" it turns off looping, or if it gets "bang" or 
"play" it starts playing. What object(s) do I use to set up something like this?

How do I set this up? I've mucked around with pack/unpack but it seems i'm 
totally barking up the wrong tree. I'm sure if I had a look at a simple example 
abstraction I'd figure it out but I'm still at the flailing about blindly stage!

 
Note I think I have a good understanding of $1 etc, creation args, and $0, 
per-instance variable thingy, which are documented well... I don't think they'd 
do what I'm after.

Thanks in advance,
Rua HM.

-- 
http://myspace.com/haszari
http://haszaristwocents.blogspot.com
http://last.fm/music/Haszari



  Easy recipes for Christmas entertaining on Yahoo!Xtra Lifestyle- 
http://nz.lifestyle.yahoo.com/food-recipes

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


[PD] GEM - nvidia GeForce 6150SE with nvidia proprietary driver and ubuntu 8.10 hangs for number of seconds

2008-11-22 Thread John Harrison
Running the nvidia proprietary driver, ubuntu 8.10 64 bit (Kernel 
2.6.27-8) an open and rending Gem window will hang the machine for 
random periods of up to 30 seconds. Problem can be triggered by clicking 
and dragging the GEM window with the mouse and trying to move the 
window. CPU appears to be maxed out during that time. I tried NVIDIA 
graphics driver version 96 and 177 and the results were the same. If I 
switch to the open source nividia driver the problem disappears --- and 
I enjoy 75% CPU usage showing only a live feed to a Gem window on a 4G 
AMD 64bit dual core. ;-)

lspci describes my graphics card as an nVidia GeForce 6150SE nForce 430 
(rev a2)

Besides using the open source driver, anybody know of a solution?

-- 
John Harrison
http://alumni.media.mit.edu/~harrison



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [polywavesynth] and [polygrainsynth] bug fix

2008-11-22 Thread Hans-Christoph Steiner

I finally had a chance to play with these, nice work!  I just spent a  
happy hour by sticking this onto the polywavesynth:

[metro 25]
|
[random 25]
|
[+ 55]
|

and other such simple things.  It sounds nice when it's thick  
changing layers.

.hc

On Oct 2, 2008, at 12:53 AM, Phil Stone wrote:

> Hi again,
>
> If you use either of these synthesizers, please grab the latest.  The
> previous versions moved "gain" to a global parameter.  I should have
> known better; this causes glitches in already-sounding notes when
> presets change.  I had a similar problem last year with  
> [polywavesynth],
> but forgot about it.
>
> This is the tradeoff to using [poly] to manage voices; if you want the
> ability to change presets cleanly, most parameters (i.e., those stored
> to make up the preset) can only be changed on new attacks.  I haven't
> thought of a way around this conundrum yet.
>
> At any rate, the latest versions fix this issue.  Sorry for any
> inconvenience.
>
> This leads to the web pages and download links for both synthesizers:
> http://www.pkstonemusic.com/pd_code.html
>
>
> Phil Stone
> http://www.pkstonemusic.com
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



 


Using ReBirth is like trying to play an 808 with a long stick.- 
David Zicarelli



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


[PD] [PD-announce] Major updates to [polygrainsynth] and [polywavesynth]

2008-11-22 Thread Phil Stone
Significant fixes and enhancements have been made to both 
[polygrainsynth] and [polywavesynth] (free polyphonic synthesizers for 
Pd).   Please try these much-improved new versions.


webpage: http://www.pkstonemusic.com/pd_code.html

some improvisations made with these instruments:  
http://www.pkstonemusic.com/pubmusic.htm


[polygrainsynth]:


2008-11-22 - v 1.0

* Added "global" toggle, which enables live output of global-capable 
parameters to all voices.
* Added "OSC-UI" toggle, which enables the UI to follow OSC input.
* Fixed many small bugs in indeterminacy (rand and drunken walk).
* Fixed bug in pointer wrap function for negative pointer hops.
* Eliminated "pointer set" slider and variable for anchoring. 
Anchored notes now start at the subsection beginning (for pointer hops 
greater than or equal to 0) or the subsection end (for pointer hops less 
than 0).
* Eliminated "rand/drunk" switch to make "rand" and "drunk" controls 
less cumbersome. Now, a zero value in these parameters is used to switch 
them off. This has the added benefit of allowing complete independence 
between hop_size and grain_dur indeterminacy controls.
* OSC nodes are all-lowercase now (e.g. /allNotesOff is now 
/allnotesoff).


[polywavesynth]:m


2008-11-22 - v 4.0

* Added "global" toggle, which enables live output of global-capable 
parameters to all voices.
* Added "OSC-UI" toggle, which enables the UI to follow OSC input.
* Made 10 of the control parameters "live" i.e., global.
* Fixed bug in "noise" wave table (only an eighth of it was 
initialized before!)
* OSC nodes are all-lowercase now (e.g. /allNotesOff is now 
/allnotesoff).



Phil Stone
http://www.pkstonemusic.com





___
Pd-announce mailing list
[EMAIL PROTECTED]
http://lists.puredata.info/listinfo/pd-announce

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] hot and cold inlets don't always make sense

2008-11-22 Thread Lao Yu
I agree about the [trigger] object - from the demo patches the  
significance didn't get through to me.

about the angriness, it is certainly my perception that tricked me -  
communicating in the writing using just a few words skips the  
niceness that we express with body language etc. this group is  
incredible helpful - I just need to count my posts and constructive  
replies received.

Best
Jurgen

On Nov 22, 2008, at 7:21 PM, Derek Holzer wrote:

> Who's angry? Arguing with strangers on the internet is about the  
> biggest waste of time I can imagine! ;-)
>
> In any case, [trigger] is the object you should investigate more,  
> as it makes the situation you want possible: change on both sides  
> of the [+] creates output.
>
> See attached.
>
> best!
> d.
>
> Lao Yu wrote:
>> Derek,
>> I went through M-P's patches, trust me. He talks a lot about  
>> looping etc but not about trivial stuff that I mentioned.
>> I knew flossmanuals but the dat flow tut escaped my notice. there  
>> is a very suitable example that is practical to me. Thank you very  
>> much for pointing me there.
>> For the sake of replying one rather angry reaction (I guess he  
>> won't read) - when incrementing a coarse / fine value of for  
>> instance tuning it is totally irrelevant which parameter is  
>> changed first. the point is to output a new value whenever either  
>> is changed. So pointing out that the hot/cold logic is essential  
>> to pd's workings doesn't even remotely give me a clue.
>> But that's ok, nobody is perfect.
>> Thanks again for the patient posters, I appreciate a lot.
>> Jurgen
>> On Nov 21, 2008, at 7:50 PM, Derek Holzer wrote:
>>> Hi Jurgen,
>>>
>>> understanding hot and cold is essential to understanding the way Pd
>>> handles order of operations, so it's best to learn it right from the
>>> start. In your example, it is unclear/ambiguous whether the fine  
>>> number
>>> gets sent to the add before or after the bang gets sent to the  
>>> coarse
>>> number. (This is determined by creation order, which cannot be  
>>> seen on
>>> the screen). This can lead to errors later.
>>>
>>> The preferred way is to use [t b f], where the [f] outlet is  
>>> connected
>>> to the cold side of the [+], and the [b] outlet is connected to  
>>> the hot
>>> side of the [+]. A bang to the hot side of many objects tells it  
>>> to do
>>> the same operation again with the information contained in the  
>>> inlets.
>>> In this case, the hot inlet will have the previous number stored  
>>> in it
>>> as well. All this is explained in Miller's HTML manual, the  
>>> "control"
>>> documentation patches, and also in the in-progress Pd FLOSS Manual:
>>> http://en.flossmanuals.net/puredata
>>>
>>> best!
>>> Derek
>>>
>>> Lao Yu wrote:
 Hi,

 when using an [+] object I find it most of the time  
 counterproductive
 that the right inlet is considered cold.

 for example, if I want to use 2 different controls for 'coarse' and
 'fine' tuning parameters it is necessary to add them together.  
 however
 when changing 'fine' value which for instance is connected to  
 the right
 inlet the new value is only taken into consideration once the  
 'coarse'
 value connected to the left inlet is changed as well.

 the only workaround I found was to [bang] the hot inlet form the  
 cold
 one as illustrated in the attached patch. but I don't find that  
 elegant.

 is there a better way to make both inlets hot?
>>>
>>> -- 
>>> derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ 
>>> macumbista
>>> ---Oblique Strategy # 7:
>>> "Accept advice"
>>>
>>> ___
>>> Pd-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>>> listinfo/pd-list
>
> -- 
> derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ 
> macumbista
> ---Oblique Strategy # 89:
> "Imagine the piece as a set of disconnected events"
> #N canvas 249 81 755 492 10;
> #X floatatom 44 142 5 0 0 0 - - -;
> #X floatatom 86 142 5 0 0 0 - - -;
> #X floatatom 44 203 5 0 0 0 - - -;
> #X obj 44 174 +;
> #X text 41 117 "hot";
> #X text 81 117 "cold";
> #X floatatom 144 142 5 0 0 0 - - -;
> #X floatatom 186 142 5 0 0 0 - - -;
> #X floatatom 144 243 5 0 0 0 - - -;
> #X obj 144 214 +;
> #X text 141 117 "hot";
> #X text 181 117 "cold";
> #X obj 186 169 trigger bang float;
> #X obj 45 343 trigger bang float;
> #X text 44 374 can be abbreviated with;
> #X obj 46 405 t b f;
> #X text 332 301 [trigger] can send an arbitrary number of things out:
> ;
> #X obj 335 343 trigger bang float anything bang bang float bang float
> ;
> #X obj 336 405 t b f a b b f b f;
> #X text 335 374 or:;
> #X text 174 452 [EMAIL PROTECTED];
> #X text 330 167 [trigger] outputs according to its creation arguments
> in right to left order. In this case \, when it receives input \, it
> will first send out a "float" (i.e. a floating poin

Re: [PD] hot and cold inlets don't always make sense

2008-11-22 Thread Derek Holzer
Who's angry? Arguing with strangers on the internet is about the biggest 
waste of time I can imagine! ;-)


In any case, [trigger] is the object you should investigate more, as it 
makes the situation you want possible: change on both sides of the [+] 
creates output.


See attached.

best!
d.

Lao Yu wrote:

Derek,

I went through M-P's patches, trust me. He talks a lot about looping etc 
but not about trivial stuff that I mentioned.


I knew flossmanuals but the dat flow tut escaped my notice. there is a 
very suitable example that is practical to me. Thank you very much for 
pointing me there.


For the sake of replying one rather angry reaction (I guess he won't 
read) - when incrementing a coarse / fine value of for instance tuning 
it is totally irrelevant which parameter is changed first. the point is 
to output a new value whenever either is changed. So pointing out that 
the hot/cold logic is essential to pd's workings doesn't even remotely 
give me a clue.


But that's ok, nobody is perfect.

Thanks again for the patient posters, I appreciate a lot.

Jurgen



On Nov 21, 2008, at 7:50 PM, Derek Holzer wrote:


Hi Jurgen,

understanding hot and cold is essential to understanding the way Pd
handles order of operations, so it's best to learn it right from the
start. In your example, it is unclear/ambiguous whether the fine number
gets sent to the add before or after the bang gets sent to the coarse
number. (This is determined by creation order, which cannot be seen on
the screen). This can lead to errors later.

The preferred way is to use [t b f], where the [f] outlet is connected
to the cold side of the [+], and the [b] outlet is connected to the hot
side of the [+]. A bang to the hot side of many objects tells it to do
the same operation again with the information contained in the inlets.
In this case, the hot inlet will have the previous number stored in it
as well. All this is explained in Miller's HTML manual, the "control"
documentation patches, and also in the in-progress Pd FLOSS Manual:
http://en.flossmanuals.net/puredata

best!
Derek

Lao Yu wrote:

Hi,

when using an [+] object I find it most of the time counterproductive
that the right inlet is considered cold.

for example, if I want to use 2 different controls for 'coarse' and
'fine' tuning parameters it is necessary to add them together. however
when changing 'fine' value which for instance is connected to the right
inlet the new value is only taken into consideration once the 'coarse'
value connected to the left inlet is changed as well.

the only workaround I found was to [bang] the hot inlet form the cold
one as illustrated in the attached patch. but I don't find that elegant.

is there a better way to make both inlets hot?


--
derek holzer ::: http://www.umatic.nl ::: 
http://blog.myspace.com/macumbista

---Oblique Strategy # 7:
"Accept advice"

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list





--
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 89:
"Imagine the piece as a set of disconnected events"
#N canvas 249 81 755 492 10;
#X floatatom 44 142 5 0 0 0 - - -;
#X floatatom 86 142 5 0 0 0 - - -;
#X floatatom 44 203 5 0 0 0 - - -;
#X obj 44 174 +;
#X text 41 117 "hot";
#X text 81 117 "cold";
#X floatatom 144 142 5 0 0 0 - - -;
#X floatatom 186 142 5 0 0 0 - - -;
#X floatatom 144 243 5 0 0 0 - - -;
#X obj 144 214 +;
#X text 141 117 "hot";
#X text 181 117 "cold";
#X obj 186 169 trigger bang float;
#X obj 45 343 trigger bang float;
#X text 44 374 can be abbreviated with;
#X obj 46 405 t b f;
#X text 332 301 [trigger] can send an arbitrary number of things out:
;
#X obj 335 343 trigger bang float anything bang bang float bang float
;
#X obj 336 405 t b f a b b f b f;
#X text 335 374 or:;
#X text 174 452 [EMAIL PROTECTED];
#X text 330 167 [trigger] outputs according to its creation arguments
in right to left order. In this case \, when it receives input \, it
will first send out a "float" (i.e. a floating point number) from its
right outlet \, then it will send a "bang" out its left outlet.;
#X text 26 20 The object [trigger] can be used to change the order
of operations in a patch by sending a message "bang" to the "hot" inlet
of an object. "Bang" means "do it now!" \, and will cause the object
to output.;
#X connect 0 0 3 0;
#X connect 1 0 3 1;
#X connect 3 0 2 0;
#X connect 6 0 9 0;
#X connect 7 0 12 0;
#X connect 9 0 8 0;
#X connect 12 0 9 0;
#X connect 12 1 9 1;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] problems with Delta 1010LT?

2008-11-22 Thread Jaime Oliver
Hello,
My problem has been solved by running alsamixer with flags to Delta-1010LT,
and raising input levels there. So, if indeed you (tim) have exactly the
same problem, then this should solve it.

J



On Sun, Nov 9, 2008 at 10:30 AM, Miller Puckette
<[EMAIL PROTECTED]>wrote:

> Wierd.  I have out-of-the-box Fedora 9 running (it's a terrible Fedora
> release, by hte way, I'm going to switch to 10 when it comes out later
> this month) and my delta1010LT runs fine.  So if it's an ALSA bug it
> must have been fixed meanwhile.
>
> BTW, there are 4 jumpers on the 1010LT card; if they are missing the first
> two inputs might not work (but the other 6 should anyway.)
>
> cheers
> Miller
>
> On Sun, Nov 09, 2008 at 04:56:48PM +0100, tim wrote:
> > hello Jamie and list,
> >
> > exact same problem here.
> > Delta1010LT outputs work, inputs don't.
> > I tried on ubuntu hardy and pure:dyne.
> > I checked all there is to check in envy24 control.
> > btw, There are also other problems showing up with alsa lately.
> > For example, the Echo Layla 3G stopped working altogether.
> > I'll try Bryan's suggestions later...
> >
> > Tim
> >
> > On Sun, 2008-11-09 at 12:36 +0100, Bryan Jurish wrote:
> > > morning Jaime,
> > >
> > > I have the same card in my desktop here under debian testing/unstable,
> > > and have also successfully used all the analog in- and outputs with pd.
> > >
> > > The only potential causes for your problem that occur to me are
> "stupid"
> > > ones that you've probably already checked, e.g. routing problems on the
> > > card [have you run "envy24control" and checked that the input levels
> > > (tab page "analog volume") are all up where they should be?]  Did you
> > > start pd with "-channels 8"?
> > >
> > > I also vaguely remember hearing of problems with the alsa mixer API
> > > (alsamixer, amixer, etc.) for envy24 cards -- the conventional wisdom
> > > seems to be: "avoid ALSA's mixer and use only envy24control for this
> > > card".  You might also check whether your distro is doing something
> > > sneaky like calling "amixer" behind your back when the driver module
> > > (snd_ice1712) is loaded (e.g. as a post-install operation declared in
> > > /etc/modules.conf)... other than that, I'm pretty much out of ideas...
>

I haven't found any file /etc/modules.conf, but I did find /etc/asound.conf

#SWCONF
#DEV 0
defaults.pcm.card 0
defaults.pcm.device 0
defaults.ctl.card 0



>
> > >
> > > marmosets,
> > > Bryan
> > >
> > > On 2008-11-09 09:06:25, "Jaime Oliver" <[EMAIL PROTECTED]>
> appears
> > > to have written:
> > > > Hello all,
> > > >
> > > > I have an M-Audio Delta 1010LT in Fedora 8. I never installed any
> > > > drivers since it seemed to work right out of the box. I have managed
> to
> > > > use the 8 channels OUT, but can't get a signal into pd in any of the
> 8
> > > > channels IN. Has anyone else seen something like this?
> > > >
> > > > best,
> > > >
> > > > J
> > > >
> > > > --
> > > > Jaime E Oliver LR
> > > >
> > > > [EMAIL PROTECTED] 
> > > > www.realidadvisual.org/jaimeoliver
> > > > 
> > > > www-crca.ucsd.edu/ 
> > > > www.realidadvisual.org 
> > > >
> > > > 858 202 1522
> > > > 9168 Regents Rd. Apt. G
> > > > La Jolla, CA 92037
> > > > USA
> > >
> > --
> > ...
> > www.timvets.net
> > [EMAIL PROTECTED], [EMAIL PROTECTED]
> > 0032 474 89 66 86
> > skype: tim167_
> > ...
> >
> >
> > ___
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
Jaime E Oliver LR

[EMAIL PROTECTED]
www.realidadvisual.org/jaimeoliver
www-crca.ucsd.edu/
www.realidadvisual.org

858 202 1522
9168 Regents Rd. Apt. G
La Jolla, CA 92037
USA
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list