Re: [PD] overdriven speaker

[Mathieu Bouchard]

On Thu, 21 Oct 2010, Martin Schied wrote:



  Isn't the heat proportional to the mean power ? Then you just do [*~] 
with itself and then some kind of [rpole~] to account for the
  accumulation thereof. After that I don't really know what to do with that.

one could feed the output of this [rpole~] into a [*~] to the input 
signal (or at any place later, but then it has to be cared for the delay 
of the doppler vd~ too, so better do it first).


Why would you be doing the doppler first ? The heat is generated first, in 
the moving coil, but the doppler is relative to the observer, who comes 
at the very end in the data flow from the amp to the ear. Thus it seems to 
me that the [vd~] should come at the very end.


How does one take the réactance into account, again ?... then we'd have to 
change the first [*~] to account for ampères not following volts, and do 
we have to change the other [*~] too ?


I think there aren't many too. The only case I can imagine and I heard 
of is for huge negative signals, where you can't go beyond 0 pascal of 
air pressure and the signal is clipped physically - but I doubt this 
ever happens in small speakers. Also I'm not sure if this only happens 
in compression speakers.


I doubt that it (getting close to 0 pascal) happens at all. It sounds more 
like a weapon of mass destruction, than like something for listening to.


Though... in some ways, it does happens, at a very small scale. What's the 
speed of air molecules, and how much time do they take to fill the void 
made by the speaker moving ? What happens if the speaker moves faster than 
that ?... (and is that actually the Doppler effect said using different 
words ?)


It has to : the speaker makes a sound by pushing and pulling on the 
air, and that changes the pressure.


To be clear, by pulling I just mean the apparent pulling that happens when 
air randomly expands to fill the void introduced by the speaker... it's 
this «pulling» that I'm talking about now.


yes, but it could also be seen in that way: the cone's travel compresses 
air in an enclosed volume. when the cone is at its travel peak (the 
acceleration is 0) the air is compressed at maximum. And I'm not sure if 
this is the case for a speaker in "free field" (not sure if that's the 
exact term) too. I know that there's something called radiation 
resistance - but I know nothing useful about it yet.


I don't know what you mean here by «enclosed volume», «free field», nor 
«radiation resistance».


sorry, I don't understand that equation I think (I'm not understanding 
difference equations very well in general) and also I have no idea of 
Laplacians until now (I'll read about it and maybe understand later)


I just mean that if you make a map of the pressure in x,y,z and t, you 
will find that normal wave transmission means that the sum of the 3 second 
spatial derivatives is proportional to the second temporal derivative. 
This can also apply if you remove the z and also if you remove the y, so 
perhaps it's easiest for you to first see that it works with just x and t.


The notation D[f,t] means something like df/dt but I don't have the 
partial derivative symbol nor the other funny notations used in math 
texts (indices, multiple-level division).


 ___
| Mathieu Bouchard -- Villeray, Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] overdriven speaker

[Mathieu Bouchard]

On Fri, 22 Oct 2010, Martin Schied wrote:

I wanted to use a fairly high a < 1 because then the phase for all 
frequencies is approximately 90° off like for the ideal a=1. Using 
slightly smaller factors and comparing input / output didn't satisfy my 
expectations. maybe that would't matter at all - let's experiment...


How is the phase preservation an important thing for you ? I ask because I 
didn't really think of it as important... (and I still somewhat don't know 
when it's really important).


that's indeed interesting. So the gain is defined for a constant signal 
having the same input and output samples (or in other words DC having no 
amplification) if I understood it correctly.


It's defined for any signal. There are different equivalent ways to define 
the gain of a linear filter. In my head, I was thinking of an input signal 
containing a single 1 in a sea of zeroes... but it might be a bit easier 
to understand it using a constant input signal. Then for [sig~ 1], [rpole~ 
1] will diverge (as much as the float32 number format can allow it to...) 
because 1/(1-1) is undefined (it's a division by zéro). But for [sig~ 1] 
again, [rpole~ 0.999] will output a constant 1000.


 ___
| Mathieu Bouchard -- Villeray, Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] overdriven speaker

[Martin Schied]

 On 22.10.2010 03:10, Mathieu Bouchard wrote:

On Fri, 22 Oct 2010, Martin Schied wrote:

yeah, but this is often the case when messing things up in pd. I 
tried rpole~ 1 with sinewaves first which worked as integrator, but 
already had different results for the output of rpole~ if the wave 
started at 0 or pi/2 (which is logic, but I didn't think about it 
first...)


um, yeah, the amount of DC is rather relative to where you start 
looking, and where you stop (or where you're at so far). That's why I 
used things like [rpole~ 0.99] to force it to recentre around 0 rather 
quickly.


I wanted to use a fairly high a < 1 because then the phase for all 
frequencies is approximately 90° off like for the ideal a=1. Using 
slightly smaller factors and comparing input / output didn't satisfy my 
expectations. maybe that would't matter at all - let's experiment...

lop's gain compensation = 1 - 0.999 = 0.001
rpole's gain to compensate for = 1/0.001 = 1000
cutoff frequency = 0.001*44100/2π = 7.019
therefore use [lop~ 7.019] with [*~ 1000] (in any order)
I thought about lop~ doing similar things too, but didn't know what 
lop~ is doing and I'm sure I wouldn't have figured it out in any 
reasonable time this morning. thanks!


Ah, I also think that you'll like to know that the total weight of an 
input sample in [rpole~ a] can be written like this :


  k = a^0 + a^1 + a^2 + a^3 + a^4 + ...
but
  a*k = a^1 + a^2 + a^3 + a^4 + ...
therefore
  k-a*k = a^0 = 1
  k*(1-a) = 1
  k = 1/(1-a) is how the gain of [rpole~] is computed above.
that's indeed interesting. So the gain is defined for a constant signal 
having the same input and output samples (or in other words DC having no 
amplification) if I understood it correctly.


I attached my [lop2~] abstraction, which is a rpole~-version of 
[lop~], with a signal-rate right-inlet. I posted it some time ago.

I remember it now, and already saved it in my mail archives :)

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

[PD] [PD-announce] mediagrid v0.2

[Husk 00]

Hey list,
after Jonathan suggestion I made an update of my mediagrid abraction.
Now it doesn't set the dirty flag (by using coord message) so it will not
ask you to save every time you close it.
And  also astupid issue whit filename and space as been solved.
You can download the new version at the same place:
http://code.autistici.org/trac/planetQ/wiki/mediagrid

cheers
husk

-- 
when Art become pratical
we call it technology.

When Technology become useless
we call it Art

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

Re: [PD] overdriven speaker

[Martin Schied]

 Hi!

I agree with Martin Peach in most points and want to add some sentences.

On 22.10.2010 01:17, Martin Peach wrote:
A perfect speaker will reproduce the sound exactly by transforming the 
instantaneous voltage to a displacement in or out. That's called 
'compliance' in the speaker biz. The ideal speaker has zero mass and 
is totally rigid.

So nonlinearities will show up:
1> when the speaker is massive and can't reach the ideal position 
quickly enough.
this mainly filters the signal in a way of an analog lowpass filter and 
influences the intensity and phase spectra. It doesn't add new 
frequencies to it, so it's still called 'linear'. However throug the 
mass the system also has to deal with the stiffness and this causes some 
nonlinear effects.
2> when the speaker deforms as it is accelerated from the centre but 
lags at the edges.
I'm also sure these material nonlinearities will produce a main part of 
distortion frequencies in the spectrum. Especially when the speaker 
surround and spider are at their limits their imperfection will cause 
the whole cone to move 'sideways' and build up different modes. So this 
is definitely of interest for a (dying) speaker simulation. Probably 
this is one of the most challenging too...


Also the stationary magnet is driving a coil in the speaker cone. When 
the speaker is overdriven the coil will be pushed away from the field 
of the magnet on the outward stroke and so the coil will be less able 
to move the speaker, so a kind of soft clipping will occur.
But on the inward stroke the coil will bottom out and slam into the 
support structure, giving a hard clipping and possibly some bouncing.
dependant on the construction of the speaker this slam will not occur, 
because the spider prevents this. (In most new speakers the spider is 
linear for small amplitudes and starts to become very hard and thus 
nonlinear at both ends. In a simulation one might want to chose if that 
slam (or i called it crash) happens or not. In a real speaker this often 
is really the death of the speaker because the coil is damaged 
permanently and then scratches on the magnet surface on every movement - 
I don't feel like I want to simulate these sounds :-\


I don't think the nonlinearities of the air are relevant here, or the 
doppler effect of the moving speaker.
I also agree that doppler effect is not the dominant parts of the 
distortions in a conventional speaker enclosure for music reproduction. 
Countermeasures are taken to reduce doppler effect as good as possible 
in these systems. In real speaker enclosements doppler effect is largely 
reduced by separating the audio spectrum on several speakers, so the 
bass speaker which does most of the movements only has to produce 
frequencies up to several hundreds of hertz. For example bass speakers 
in 3-ways systems are driven below 150 Hz in most cases - doppler effect 
becomes very low in this spectrum and mid range speaker have almost no 
visible travel anymore. However the doppler effect occurs in every 
speaker with moving parts and especially for full range speakers this 
becomes important. Guitar amps often use bass drivers in full range, so 
this has some practical relevance for musicians too.


I'd be interested what kind of speakers fallen_devil was interested in 
when originally posting his question to the list. Also a record of the 
noise would be nice for comparison...


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

Re: [PD] overdriven speaker

[Mathieu Bouchard]

On Fri, 22 Oct 2010, Martin Schied wrote:

yeah, but this is often the case when messing things up in pd. I tried 
rpole~ 1 with sinewaves first which worked as integrator, but already 
had different results for the output of rpole~ if the wave started at 0 
or pi/2 (which is logic, but I didn't think about it first...)


um, yeah, the amount of DC is rather relative to where you start looking, 
and where you stop (or where you're at so far). That's why I used things 
like [rpole~ 0.99] to force it to recentre around 0 rather quickly.



    lop's gain compensation = 1 - 0.999 = 0.001
    rpole's gain to compensate for = 1/0.001 = 1000
    cutoff frequency = 0.001*44100/2π = 7.019
    therefore use [lop~ 7.019] with [*~ 1000] (in any order)
I thought about lop~ doing similar things too, but didn't know what lop~ 
is doing and I'm sure I wouldn't have figured it out in any reasonable 
time this morning. thanks!


Ah, I also think that you'll like to know that the total weight of an 
input sample in [rpole~ a] can be written like this :


  k = a^0 + a^1 + a^2 + a^3 + a^4 + ...
but
  a*k = a^1 + a^2 + a^3 + a^4 + ...
therefore
  k-a*k = a^0 = 1
  k*(1-a) = 1
  k = 1/(1-a) is how the gain of [rpole~] is computed above.

I attached my [lop2~] abstraction, which is a rpole~-version of [lop~], 
with a signal-rate right-inlet. I posted it some time ago.


 ___
| Mathieu Bouchard -- Villeray, Montréal, QC#N canvas 465 194 328 107 10;
#X obj 191 26 samplerate~;
#X obj 191 7 loadbang;
#X obj 7 45 *~;
#X obj 7 64 rpole~;
#X obj 7 26 inlet~;
#X obj 7 83 outlet~;
#X obj 49 26 inlet~;
#X obj 50 45 expr~ $v1*3.141593*2/$v2;
#X obj 49 64 expr~ 1-$v1;
#X text 57 82 signal-rate [lop~] by Mathieu Bouchard 2010;
#X connect 0 0 7 1;
#X connect 1 0 0 0;
#X connect 2 0 3 0;
#X connect 3 0 5 0;
#X connect 4 0 2 0;
#X connect 6 0 7 0;
#X connect 7 0 8 0;
#X connect 7 0 2 1;
#X connect 8 0 3 1;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] overdriven speaker

[Martin Schied]

 Hi!

On 21.10.2010 07:17, Mathieu Bouchard wrote:

On Thu, 21 Oct 2010, Martin Schied wrote:

It shouldn't be too hard to do this integration with basic pole / 
zero objects. A problem using integration only is the lack of 
mechanical damping. A real speaker goes back to x=0 if no signal is 
present. A simple integrator doesn't


right. That's why you can't just use [rpole~ 1]. Then, any [rpole~] 
with a value between 0 and 1 will act as a convolution with an 
exponential decay function. An integral is a convolution with a 
constant function, such as exp(0*t).
nice way to look at it. I used the formulation y[n] = x[n]+ a[n] * 
y[n-1] in the help files and some semi-knowledge about filters...


Because the integral of the exponential decay function is bigger than 
1, the result of [rpole~] will have some amount of gain.



- so the 'simulated' cone would just fly away slowly.


That's only in the case where the signal has a DC.
yeah, but this is often the case when messing things up in pd. I tried 
rpole~ 1 with sinewaves first which worked as integrator, but already 
had different results for the output of rpole~ if the wave started at 0 
or pi/2 (which is logic, but I didn't think about it first...)



[rpole~ 0.999] does it very well...


Note that [rpole~] is dependent on sampling rate. So, assuming you 
have a sampling rate of 44100 Hz, the rate-independent way to do it is :


  lop's gain compensation = 1 - 0.999 = 0.001
  rpole's gain to compensate for = 1/0.001 = 1000
  cutoff frequency = 0.001*44100/2π = 7.019
  therefore use [lop~ 7.019] with [*~ 1000] (in any order)
I thought about lop~ doing similar things too, but didn't know what lop~ 
is doing and I'm sure I wouldn't have figured it out in any reasonable 
time this morning. thanks!


cheers
Martin

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

Re: [PD] [PD-announce] Another Feature Extraction Library

[Peter Plessas]

Dear Adriano,

thank you for posting this!
Have you already thought about registering with puredata.org and hosting 
your great abstractions there, along with many excellent contributions 
by other members of the pure data community?


best,
P.

Adriano Monteiro wrote:

Hi list,

I'm writing to make available to you a feature extraction library that I
implemented as abstractions in PD

It can be useful for people who are also studying this subject and other
things related to it.

Here is the google site with the library attached for download:

https://sites.google.com/site/pdescriptors/

I hope you enjoy it

Best

Adriano





___
Pd-announce mailing list
pd-annou...@iem.at
http://lists.puredata.info/listinfo/pd-announce




___
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

Re: [PD] reverb in pd

[Peter Plessas]

saint wrote:

+1 on ben saylor's partconv~ - works excellently.

arm yourself with the free acousticas IR's...
http://www.acousticas.net/World/IRs/AcousticasM7.zip

of the $3,500 bricasti m7 unit...
http://www.bricasti.com/m7.html

...and you'll not go back to algorithmic reverbs again.

or just get some balloons and record your own!

Or even better use Fons' great application Aliki:
http://www.kokkinizita.net/linuxaudio/
lac.zkm.de/2006/papers/lac2006_fons_adriaensen_01.pdf

best,
P.

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

Re: [PD] overdriven speaker

[Martin Peach]

A perfect speaker will reproduce the sound exactly by transforming the 
instantaneous voltage to a displacement in or out. That's called 
'compliance' in the speaker biz. The ideal speaker has zero mass and is 
totally rigid.

So nonlinearities will show up:
1> when the speaker is massive and can't reach the ideal position 
quickly enough.
2> when the speaker deforms as it is accelerated from the centre but 
lags at the edges.


Also the stationary magnet is driving a coil in the speaker cone. When 
the speaker is overdriven the coil will be pushed away from the field of 
the magnet on the outward stroke and so the coil will be less able to 
move the speaker, so a kind of soft clipping will occur.
But on the inward stroke the coil will bottom out and slam into the 
support structure, giving a hard clipping and possibly some bouncing.


I don't think the nonlinearities of the air are relevant here, or the 
doppler effect of the moving speaker.


Cavitation might occur with an underwater speaker, where bubbles are 
formed by the negative pressure on the trailing side of the cone.


Martin


On 2010-10-21 11:48, Martin Schied wrote:

Hi!



Looking at power and air pressure - we don't have to care about them
as long as we don't want to include thermal effects


Isn't the heat proportional to the mean power ? Then you just do [*~]
with itself and then some kind of [rpole~] to account for the
accumulation thereof. After that I don't really know what to do with that.

one could feed the output of this [rpole~] into a [*~] to the input
signal (or at any place later, but then it has to be cared for the delay
of the doppler vd~ too, so better do it first). The exact parameters can
be found by experiments, but as written in an earlier mail the signal
reduction can be up to 7dB (I would use slightly more). I don't have
time right now, but maybe I'll experiment  later...



or nonlinearities of the air I think.


I don't know them at all. I've never heard of anyone taking them into
account.

I think there aren't many too. The only case I can imagine and I heard
of is for huge negative signals, where you can't go beyond 0 pascal of
air pressure and the signal is clipped physically - but I doubt this
ever happens in small speakers. Also I'm not sure if this only happens
in compression speakers.



The pressure directly in front of the cone is related to the
acceleration I think, but I'm not sure about that.


It has to : the speaker makes a sound by pushing and pulling on the
air, and that changes the pressure.

yes, but it could also be seen in that way: the cone's travel compresses
air in an enclosed volume. when the cone is at its travel peak (the
acceleration is 0) the air is compressed at maximum. And I'm not sure if
this is the case for a speaker in "free field" (not sure if that's the
exact term) too. I know that there's something called radiation
resistance - but I know nothing useful about it yet.



Can anybody confirm that? I think that's not trivial to answer
anyways, because already 10cm farther from the speaker the pressure
and air velocity are different.


It has to... the reason why you hear the sound and why sound has a
speed, is because neighbouring pressure differences cause pressure
differences to propagate. It's a second-order differential equation,
as the position of air particles is proportional to their
acceleration. The Laplacian of the wave function along x,y,z is
proportional to the 2nd derivative of the wave function along t... I'd
write it like :

  D[D[f,x],x] + D[D[f,y],y] + D[D[f,z],z] = D[D[f,t],t] / v²

Where v² is the square of the speed of sound.

With a slight coordinate change using imaginary numbers, you can see
it as a Laplacian along x,y,z,t instead, in 4-dimensional spacetime,
and the Laplacian is equal to zero. But that's only if the air is
considered frictionless :)

sorry, I don't understand that equation I think (I'm not understanding
difference equations very well in general) and also I have no idea of
Laplacians until now (I'll read about it and maybe understand later)



Ah, that means that the mechanical amplitude (travel) of the wave is
much smaller for treble than bass, is that right ?

exactly.

cheers
Martin



___
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

Re: [PD] OSC messages without /

[Martin Peach]

On 2010-10-21 13:26, Leandro da Mota Damasceno wrote:

Hey guys

So, I am working with a Max/MSP standalone application that sends OSC
messages through UDP, but it's not using any / signs in the beginning of
the message. So I'm getting the following in PD

unpackOSC: Path doesn't begin with "/", dropping message


Maybe you could post the actual Pd patch you used to get this result?

Martin

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

Re: [PD] OSC messages without /

[Leandro da Mota Damasceno]

Hi Roman

Thanks for the help. Actually, I did not write the code in Max/MSP, but I
think I will end up writing my own version of the application, because it
does need a lot of tweaking. It is funny to realize how Max/MSP can be kind
of agnostic towards that.

Well, I will try your patch. I hope it works. I'm getting sick of my patch
already :P

best,

Leandro

On Thu, Oct 21, 2010 at 11:07 PM, Roman Haefeli  wrote:

> Hi again
>
> (I reply to the  list as well...)
>
> Yeah, I now remember that the OSC address must always be a multiple of 4
> bytes long. I also stumbled across this problem a while ago and wrote an
> abstraction back then that does pad the the address of the OSC message
> with zeros as needed. Insert it right after the [list prepend 47].
>
> Check attachment.
>
> Although this might work now, it's clearly the fault of your max/msp
> patch that obviously does not comply with the OSC standard.
>
> Roman
>
>
> On Thu, 2010-10-21 at 22:45 +0200, Leandro da Mota Damasceno wrote:
> > That solution sounded good, but this is the result I got:
> >
> >
> >
> >
> > unpackOSC: Packet size (257) not a multiple of 4 bytes: dropping
> > packet
> > unpackOSC: Packet size (41) not a multiple of 4 bytes: dropping packet
> > unpackOSC: Packet size (281) not a multiple of 4 bytes: dropping
> > packet
> > unpackOSC: Packet size (41) not a multiple of 4 bytes: dropping packet
> > unpackOSC: Packet size (281) not a multiple of 4 bytes: dropping
> > packet
> > unpackOSC: Packet size (41) not a multiple of 4 bytes: dropping packet
> > unpackOSC: Packet size (281) not a multiple of 4 bytes: dropping
> > packet
> >
> >
> > and so on. Any ideas?
> >
> > On Thu, Oct 21, 2010 at 10:07 PM, Roman Haefeli 
> > wrote:
> > On Thu, 2010-10-21 at 19:39 +0100, Claude Heiland-Allen wrote:
> > > On 21/10/10 18:26, Leandro da Mota Damasceno wrote:
> > > > So, the question is... Is there any workaround I could try
> > in PD?
> > >
> > >   |
> > > [list split 1]
> > >   |  |
> > > "/$1"   |
> > >   |  |
> > > [list append ]
> > >   |
> > > [list trim]
> > >   |
> >
> >
> > This would require to convert the byte list to strings and
> > then back to
> > a byte list again.
> >
> > You could instead insert a [list prepend 47] (47 is the byte
> > value of a
> > '/') right after the [udpreceive].
> >
> > Roman
> >
> >
> >
> >
> > ___
> > 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

Re: [PD] OSC messages without /

[Roman Haefeli]

Hi again

(I reply to the  list as well...)

Yeah, I now remember that the OSC address must always be a multiple of 4
bytes long. I also stumbled across this problem a while ago and wrote an
abstraction back then that does pad the the address of the OSC message
with zeros as needed. Insert it right after the [list prepend 47].

Check attachment.

Although this might work now, it's clearly the fault of your max/msp
patch that obviously does not comply with the OSC standard.

Roman


On Thu, 2010-10-21 at 22:45 +0200, Leandro da Mota Damasceno wrote:
> That solution sounded good, but this is the result I got:
> 
> 
> 
> 
> unpackOSC: Packet size (257) not a multiple of 4 bytes: dropping
> packet
> unpackOSC: Packet size (41) not a multiple of 4 bytes: dropping packet
> unpackOSC: Packet size (281) not a multiple of 4 bytes: dropping
> packet
> unpackOSC: Packet size (41) not a multiple of 4 bytes: dropping packet
> unpackOSC: Packet size (281) not a multiple of 4 bytes: dropping
> packet
> unpackOSC: Packet size (41) not a multiple of 4 bytes: dropping packet
> unpackOSC: Packet size (281) not a multiple of 4 bytes: dropping
> packet
> 
> 
> and so on. Any ideas?
> 
> On Thu, Oct 21, 2010 at 10:07 PM, Roman Haefeli 
> wrote:
> On Thu, 2010-10-21 at 19:39 +0100, Claude Heiland-Allen wrote:
> > On 21/10/10 18:26, Leandro da Mota Damasceno wrote:
> > > So, the question is... Is there any workaround I could try
> in PD?
> >
> >   |
> > [list split 1]
> >   |  |
> > "/$1"   |
> >   |  |
> > [list append ]
> >   |
> > [list trim]
> >   |
> 
> 
> This would require to convert the byte list to strings and
> then back to
> a byte list again.
> 
> You could instead insert a [list prepend 47] (47 is the byte
> value of a
> '/') right after the [udpreceive].
> 
> Roman
> 
> 
> 
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> 
> 
> 

#N canvas 520 86 354 302 10;
#N canvas 393 132 493 501 realign 0;
#N canvas 1048 333 213 342 find 0;
#X obj 15 124 list split 1;
#X obj 15 77 until;
#X obj 15 99 list append;
#X obj 122 118 bang;
#X obj 15 14 inlet;
#X obj 15 43 t b a b;
#X obj 15 152 t a b;
#X obj 47 176 f;
#X obj 47 200 + 1;
#X msg 65 152 0;
#X obj 15 228 sel 44;
#X obj 15 252 f;
#X obj 15 306 outlet;
#X obj 15 275 - 1;
#X connect 0 0 6 0;
#X connect 0 1 2 1;
#X connect 0 2 3 0;
#X connect 1 0 2 0;
#X connect 2 0 0 0;
#X connect 3 0 1 1;
#X connect 4 0 5 0;
#X connect 5 0 1 0;
#X connect 5 1 2 1;
#X connect 5 2 9 0;
#X connect 6 0 10 0;
#X connect 6 1 7 0;
#X connect 7 0 8 0;
#X connect 8 0 7 1;
#X connect 8 0 11 1;
#X connect 9 0 7 1;
#X connect 10 0 11 0;
#X connect 10 0 3 0;
#X connect 11 0 13 0;
#X connect 13 0 12 0;
#X restore 82 67 pd find 44;
#X obj 15 34 t a a;
#X obj 15 96 list split;
#N canvas 46 270 341 337 strip 0;
#X obj 35 128 list split 1;
#X obj 35 81 until;
#X obj 35 103 list append;
#X obj 142 122 bang;
#X obj 15 14 inlet;
#X obj 160 175 t a;
#X obj 67 175 list prepend;
#X obj 15 45 t b b a b;
#X obj 15 210 list append;
#X obj 35 151 sel 0;
#X obj 195 122 b;
#X obj 15 233 outlet;
#X connect 0 0 9 0;
#X connect 0 1 2 1;
#X connect 0 2 3 0;
#X connect 1 0 2 0;
#X connect 2 0 0 0;
#X connect 3 0 1 1;
#X connect 4 0 7 0;
#X connect 5 0 6 1;
#X connect 6 0 5 0;
#X connect 6 0 8 1;
#X connect 7 0 8 0;
#X connect 7 1 1 0;
#X connect 7 2 2 1;
#X connect 7 3 10 0;
#X connect 8 0 11 0;
#X connect 9 1 6 0;
#X connect 10 0 6 1;
#X connect 10 0 8 1;
#X restore 15 135 pd strip 0;
#X obj 47 230 mod 4;
#X obj 47 251 sel 0 1 2 3;
#X msg 47 331 0 0 0 0;
#X msg 65 311 0 0 0;
#X msg 84 292 0 0;
#X msg 102 272 0;
#X obj 15 378 list append;
#X obj 15 428 list append;
#X obj 15 180 t a a;
#X obj 47 208 list length;
#X obj 15 9 inlet;
#X text 168 67 find start of type tag: 44 = \,;
#X text 101 135 strip any trailing zeros from OSC adress pattern;
#X text 135 307 align OSC address to a multiple of 4 bytes;
#X text 113 430 join OSC address and rest of OSC packet;
#X obj 15 452 outlet;
#X text 113 96 split OSC address pattern from rest of OSC packet;
#X connect 0 0 2 1;
#X connect 1 0 2 0;
#X connect 1 1 0 0;
#X connect 2 0 3 0;
#X connect 2 1 11 1;
#X connect 3 0 12 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 5 1 7 0;
#X connect 5 2 8 0;
#X connect 5 3 9 0;
#X connect 6 0 10 1;
#X connect 7 0 10 1;
#X connect 8 0 10 1;
#X connect 9 0 10 1;
#X connect 10 0 11 0;
#X connect 11 0 19 0;
#X connect 12 0 10 0;
#X connect 12 1 13 0;
#X connect 13 0 4 0;
#X connect 14 0 1 0;
#X restore 21 32 pd realign;
#X obj 21 9 inlet;
#X obj 21 53 outlet;
#X connect 0 0 2 0;
#X connect 1 0 0 0;

Re: [PD] Arduino Mega support with Pduino

[Hans-Christoph Steiner]

Good to hear!  Now we have to sort of the troubles with the Uno...

.hc

On Oct 21, 2010, at 12:16 PM, olsen wrote:

sorry4delay but finally i got my hands free for testing it on an  
Arduino Mega(Atmega1280) with the new arduino21 feat. firmata-2.2 &  
Pduino-0.5beta8


__DigitalInput
Works all the way up to Pin 53 - all Pins corresponding to Pins  
number in Pduino-test.pd

__DigitalOutput
Same here
__PWM
works for all PWM pins from 2-13
__servo
works for all PWM pins from 2-13
__AnalogInput
on Pin 0-15 getting proper input

seems like getting full marks for this piece of software

thanks hans et al.!
salutis
ø



On 09/04/2010 01:52 AM, Hans-Christoph Steiner wrote:


So I am just coming back to trying to support the Arduino Mega. I  
think

the situation is improved, but not perfect. The Arduino Mega's pin
numbering mess will always make things confusing, IMHO. The latest
Firmata is included in Arduino 0019 RC2, so that's the thing to use  
to

test it. Here's how to get Arduino 0019 RC2:

http://arduino.cc/pipermail/developers_arduino.cc/2010-August/003224.html

.hc

On Mar 30, 2010, at 7:21 AM, olsen wrote:


Ej Hans
very nice! i went back to my flock of arduinos for testing.
with the duemilanueve/328 ev'ry thing seems to work fine!
though with the Mega there's some lack in the well-behaviour that i
would like to report:

__DigitalInput
No DigitalInput on Pins 0 to 8 and 12&13
Putting a physical digital input on pin 9 to 11 in pduino the state
for all these pins is always displayed on digital input 12!

__DigitalOutput
DigitalOutput only on Pin 10-13 and to get pin 13 high i've to
checkerbox pin 15 in pduino

Seems there's some kind of trouble with the Pin settings and their
represenation in pduino.

__PWM
pwm output is working on the proper Pins & from Pin 2 to 10 & 13 -  
on

Pin 11 and 12 i could not get any pwm out.

__servo
servo output is working on the proper Pins & from Pin 2 to 13!

__AnalogInput
Pin 0-7 giving here proper input

i'll get the nano testing within the next days & also try to get my
hands dirty for some testing on OSX
if there's anything else i could help ping me up!
thanks again for this nice piece of software! to my experience so  
far
for pd/arduino-newbies pduino is pretty much facilitating  
sensorymotor

processing!
thumbs up & salutis
ø



Hans-Christoph Steiner wrote:

Now that Firmata 2.1 is released and included in Arduino 0018, we
have a new beta release for the Pduino [arduino] object. There were
lots of cleanups and fixes on test and help patch, and the addition
of symbols like "input", "analog", etc. to the [pinMode ( message.
http://at.or.at/hans/pd/objects.html#pduino
I tested this on a Diecimila and original Arduino. These are the  
only

Arduinos I have, so testing and bug reports on those are very
helpful. There are no outstanding bugs that I know of, if I hear of
no other bugs, I think this one will be the final release!
.hc

"[W]e have invented the technology to eliminate scarcity, but we  
are

deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
___
Pd-announce mailing list
pd-annou...@iem.at
http://lists.puredata.info/listinfo/pd-announce
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list


--
ETs DNA will not be televised


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






"A cellphone to me is just an opportunity to be irritated wherever  
you

are." - Linus Torvalds



--
ETs DNA will not be televised
http://hasa-labs.org






I hate it when they say, "He gave his life for his country."  Nobody  
gives their life for anything.  We steal the lives of these kids.  - 
Admiral Gene LeRocque



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

Re: [PD] OSC messages without /

[Roman Haefeli]

On Thu, 2010-10-21 at 19:39 +0100, Claude Heiland-Allen wrote:
> On 21/10/10 18:26, Leandro da Mota Damasceno wrote:
> > So, the question is... Is there any workaround I could try in PD?
> 
>   |
> [list split 1]
>   |  |
> "/$1"   |
>   |  |
> [list append ]
>   |
> [list trim]
>   |

This would require to convert the byte list to strings and then back to
a byte list again.

You could instead insert a [list prepend 47] (47 is the byte value of a
'/') right after the [udpreceive].

Roman
 


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

Re: [PD] reverb in pd

[Pierre Massat]

This is awesome! Strickly so. Thanks!

How does partitioned convolution work?

Pierre

2010/10/21 saint 

> +1 on ben saylor's partconv~ - works excellently.
>
> arm yourself with the free acousticas IR's...
> http://www.acousticas.net/World/IRs/AcousticasM7.zip
>
> of the $3,500 bricasti m7 unit...
> http://www.bricasti.com/m7.html
>
> ...and you'll not go back to algorithmic reverbs again.
>
> or just get some balloons and record your own!
>
> (grab those IR's soon as it seems acousticas have gone out of business.
> took me a few attempts to check but the link is working.)
>
>
>
>
> ___
> 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

[PD] Atencion usuarios de Pd en Puerto Rico/ Attention Pd user in Puerto Rico

[Jeffrey Concepcion]

Si hay alguien mas en Puerto Rico que utiliza Pd o Max debemos encontrarnos
para compartir nuestro conocimiento y no estar siempre trabajando solitos
por ahi. Efectivamente hacer nuestro PR Patching Circle.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] OSC messages without /

[Claude Heiland-Allen]

On 21/10/10 18:26, Leandro da Mota Damasceno wrote:

So, the question is... Is there any workaround I could try in PD?


 |
[list split 1]
 |  |
"/$1"   |
 |  |
[list append ]
 |
[list trim]
 |

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

Re: [PD] OSC messages without /

[Mathieu Bouchard]

On Thu, 21 Oct 2010, Leandro da Mota Damasceno wrote:

Like, a lot. It just ignores the messages because of the lack of the 
"/". Since the standalone application was made by Max/MSP users, they 
ignored this apparent limitation on PD. In fact, I tried in Max/MSP with 
a udpreceive object linked to a route and it already got me results.


What does the OSC standard say about leading slashes ?

 ___
| Mathieu Bouchard -- Villeray, Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] OSC messages without /

[IOhannes m zmölnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/21/2010 07:26 PM, Leandro da Mota Damasceno wrote:
> Hey guys
> 
> So, I am working with a Max/MSP standalone application that sends OSC
> messages through UDP, but it's not using any / signs in the beginning of the
> message. So I'm getting the following in PD

afaik, in this case it is not OSC.
you are probably sending something with your max [updsender] oject (or
how it is called), but it is not OSC.
http:/opensoundcontrol.org

fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzAeIcACgkQkX2Xpv6ydvTcmACfTULywXeUx/l8UIzA2LN4CgzG
dv8AoM2M5oUW0obX19xWPRq2vpJoHmFX
=TQDe
-END PGP SIGNATURE-

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

[PD] OSC messages without /

[Leandro da Mota Damasceno]

Hey guys

So, I am working with a Max/MSP standalone application that sends OSC
messages through UDP, but it's not using any / signs in the beginning of the
message. So I'm getting the following in PD

unpackOSC: Path doesn't begin with "/", dropping message

Like, a lot. It just ignores the messages because of the lack of the "/".
Since the standalone application was made by Max/MSP users, they ignored
this apparent limitation on PD. In fact, I tried in Max/MSP with a
udpreceive object linked to a route and it already got me results.

So, the question is... Is there any workaround I could try in PD?

Best

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

Re: [PD] [PD-announce] [arte + innovación] T aller de Algoritmia 2010

[jm jones]

2010/10/21 Correa Diego :
Maybe you would want to shorten it?
This is the body of the traduction:
>
>
>
> Dear friends,
> The second year of activities of "Taller de Algoritmia"
> include new modules and applied knowledge in art
> aesthetic as well as a more direct relationship with innovation
> in relation to the new environment that welcomes us in 2010. We are pleased
> to report that with support from the government's institution for promotion
> on production, CORFO, through its new archives and library area, practical
> modules
> on innovation and aesthetics will be held in by this new premises in
> Moneda Street 921, Santiago (Chile), second floor, in its Patrimonial Room,
> from about the second week of November of this year.
> The modules called for this year are:
> ISA:: Introduction to Analog Sensors for Interactive Interfaces
> ICG:: Introduction to Computer Graphics
> IPD:: Introduction to Pure Data (Pd)
> ISM:: Introduction to Microcontrollers Sensors
> IBE:: Instrumentation Bioelectronics
> ISS:: Introduction to Sound Synthesis with Pd
> IMMVP:: Introduction to Method in Music and Video-Performance with Pd
> IOSC:: Introduction to Open Sound Control (OSC)
> SSII:: Wireless Sensors
> CCDD: Digital Controllers
> IMMEPD:: Introduction to Methods in Electronic Music with Pd
> IOCV:: Introduction to Open Computer Vision (OpenCV)
> IEM:: Electronic Musical Instruments
> I also want to welcome Hector and Marco Capossiello
> Colasso, comprising this year's workshop. From their
> areas of expertise, will guide the new modules proposed;
> Computer Graphics and Sound Synthesis respectively.
> I remember the true commitment that the workshop had have from a
> beginning, with the use of free license logic for
> multiple platforms, as an effective way of disseminating
> details that make useful algorithmic methods participate in the common
> domain
> , while maintaining the original appropriation and intellectual
> industrial processes involved.
> From now I send my warmest greetings to all (as) you
>
> I remain yours,
> Diego Correa T.
> Coordinator
> Taller de Algoritmia 2010
> http://labormedia.cl/algoritmia
>
>
> 2010/10/21 Correa Diego 
>>
>> Hi Marco,
>> I'm very thankful for your interest in the publication of our activities.
>> I will give it a turn and I'll send you the traduction the next hour.
>> fair enough?
>>
>> best wishes,
>>
>> Diego
>>
>> 2010/10/21 Marco Donnarumma 
>>>
>>> Hi Diego,
>>> Marco Donnarumma here from Pd-list.
>>>
>>> I run a blog about open source culture and media art at
>>> http://www.thesaddj.com and I'd like to post a news about this series of
>>> workshops.
>>> Perhaps you have an English version of the call?
>>>
>>> I could translate with some tools but it could be faster and easier if
>>> you had a translation already.
>>> Thanks,
>>>
>>> Best wishes,
>>>
>>> Marco
>>>
>>>
>>> 2010/10/19 Correa Diego 

 Estimados(as),
 El segundo año de actividades de "Taller de Algoritmia" contemplará
 nuevos módulos de conocimientos aplicados en arte y estética, además de una
 relación aún más directa con la innovación en relación al nuevo espacio que
 nos acoge este 2010. Nos es grato informar que gracias al apoyo de Corfo, a
 través de su nueva área de archivos y biblioteca, los módulos prácticos en
 innovación y estética se realizarán en sus nuevas dependencias ubicadas en
 calle Moneda 921, Santiago; segundo piso, sala patrimonial; a partir de la
 segunda semana de noviembre.
 Los módulos convocados para este año son:
 ISA    ::  Introducción a Sensores Análogos para Interfaces Interactivas
 ICG    ::  Introducción a Computer Graphics
 IPD    ::  Introducción a Pure Data (Pd)
 ISM    ::  Introducción a Sensores con Microcontroladores
 IBE    ::  Instrumentación Bioelectrónica
 ISS    ::  Introducción a la Síntesis de Sonidos con Pd
 IMMVP  ::  Introducción a Método en Música y Video-Performance con Pd
 IOSC   ::  Introducción a Open Sound Control (OSC)
 SSII   ::  Sensores Inalámbricos
 CCDD   ::  Controladores Digitales
 IMMEPD ::  Introducción a Métodos en Música Electrónica con Pd
 IOCV   ::  Introducción a Open Computer Vision (OpenCV)
 IEM    ::  Instrumentos Electrónicos Musicales
 También quiero dar la bienvenida a Hector Capossiello y Marco Colasso,
 que integran este año el taller. Desde sus respectivas áreas de expertise,
 guiarán los nuevos módulos propuestos en Computer Graphics y Síntesis de
 Sonido respectivamente.
 Debo recordar el fiel compromiso que el taller ha tenido desde un inicio
 con la utilización de lógica de licencia libre para múltiples plataformas,
 como una vía efectiva de divulgar los detalles que hacen de los métodos
 algorítmicos un bien de dominio común, sin desmedro de la apropiación
 original, intelectual e industrial de los procesos implicados.
 Desde ya les envío mis saludos más cordiales a todos(as) 

Re: [PD] Arduino Mega support with Pduino

[olsen]

sorry4delay but finally i got my hands free for testing it on an Arduino Mega(Atmega1280) with the new arduino21 feat. 
firmata-2.2 & Pduino-0.5beta8


__DigitalInput
Works all the way up to Pin 53 - all Pins corresponding to Pins number in 
Pduino-test.pd
__DigitalOutput
Same here
__PWM
works for all PWM pins from 2-13
__servo
works for all PWM pins from 2-13
__AnalogInput
on Pin 0-15 getting proper input

seems like getting full marks for this piece of software

thanks hans et al.!
salutis
ø



On 09/04/2010 01:52 AM, Hans-Christoph Steiner wrote:


So I am just coming back to trying to support the Arduino Mega. I think
the situation is improved, but not perfect. The Arduino Mega's pin
numbering mess will always make things confusing, IMHO. The latest
Firmata is included in Arduino 0019 RC2, so that's the thing to use to
test it. Here's how to get Arduino 0019 RC2:

http://arduino.cc/pipermail/developers_arduino.cc/2010-August/003224.html

.hc

On Mar 30, 2010, at 7:21 AM, olsen wrote:


Ej Hans
very nice! i went back to my flock of arduinos for testing.
with the duemilanueve/328 ev'ry thing seems to work fine!
though with the Mega there's some lack in the well-behaviour that i
would like to report:

__DigitalInput
No DigitalInput on Pins 0 to 8 and 12&13
Putting a physical digital input on pin 9 to 11 in pduino the state
for all these pins is always displayed on digital input 12!

__DigitalOutput
DigitalOutput only on Pin 10-13 and to get pin 13 high i've to
checkerbox pin 15 in pduino

Seems there's some kind of trouble with the Pin settings and their
represenation in pduino.

__PWM
pwm output is working on the proper Pins & from Pin 2 to 10 & 13 - on
Pin 11 and 12 i could not get any pwm out.

__servo
servo output is working on the proper Pins & from Pin 2 to 13!

__AnalogInput
Pin 0-7 giving here proper input

i'll get the nano testing within the next days & also try to get my
hands dirty for some testing on OSX
if there's anything else i could help ping me up!
thanks again for this nice piece of software! to my experience so far
for pd/arduino-newbies pduino is pretty much facilitating sensorymotor
processing!
thumbs up & salutis
ø



Hans-Christoph Steiner wrote:

Now that Firmata 2.1 is released and included in Arduino 0018, we
have a new beta release for the Pduino [arduino] object. There were
lots of cleanups and fixes on test and help patch, and the addition
of symbols like "input", "analog", etc. to the [pinMode ( message.
http://at.or.at/hans/pd/objects.html#pduino
I tested this on a Diecimila and original Arduino. These are the only
Arduinos I have, so testing and bug reports on those are very
helpful. There are no outstanding bugs that I know of, if I hear of
no other bugs, I think this one will be the final release!
.hc

"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
___
Pd-announce mailing list
pd-annou...@iem.at
http://lists.puredata.info/listinfo/pd-announce
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list


--
ETs DNA will not be televised


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






"A cellphone to me is just an opportunity to be irritated wherever you
are." - Linus Torvalds



--
ETs DNA will not be televised
http://hasa-labs.org


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

Re: [PD] line: grain rate and delta

[Frank Barknecht]

Hi Tim,

On Thu, Oct 21, 2010 at 05:51:20PM +0200, tim vets wrote:
> the way I understood it, [delta] is the equivalent of:
> [image: delta.png]
> I also don't know where I got [delta] from, it doesn't seem to have a help
> patch associated with it.

Maybe it's the [delta] from maxlib. I attached its help file. 

Btw.: Your delta.png can be simplyfied a bit as:

 [t f f]
   \/
   /\
  [- ]

Ciao
-- 
 Frank BarknechtDo You RjDj.me?  _ __footils.org__


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

Re: [PD] line: grain rate and delta

[tim vets]

2010/10/21 tim vets 

>
>
> 2010/10/21 IOhannes zmölnig 
>
> On 10/21/2010 03:30 PM, tim vets wrote:
>> > Hi all,
>> > I'm a bit confused about the grain rate of [line]
>> > the help says that 'the default grain rate is 20 ms'
>> > however, when I connect a [delta] to a [line], it shows zero's,
>> > while inserting a [speedlim 20] changes that.
>> > also some other tests in attached patch.
>> > can someone explain ?
>>
>> as matju already stated, [delta] is something, a lot of people
>> (including me) do not know.
>>
>> assuming it is the same as:
>> |
>> [t b b]
>> | |
>> [timer]
>> |
>>
>> then it "looks" like you get "0", whereas in reality you get:
>> [20, 0( [*]
>>
>> the "20" shows up so incredibly short (and is then overwritten by "0",
>> that you simply cannot see it.
>> [print] usually allows you to track such things, as you not only see the
>> last value, but the entire history.
>>
>> [*] why?
>> when [line] receives a new target, it will immediately send out the
>> start value, and then (in grain-time ms) the next value until it reaches
>> the target value.
>> in your case this translates to:
>> - you generate the first number ("7") and send [7 20( to [line]
>> - line will immediately output the current value ("0") and after 20ms it
>> will output the next value ("7")
>> - at the "same" time, you generate a new value ("9"), and send this to
>> [line], which will immediately output the current value ("7").
>>
>> since both the start value and the target value are output at the same
>> logical time, [timer] caluculates a time-difference of "0", which will
>> be visible for the next 20ms.
>>
>>
>
> the way I understood it, [delta] is the equivalent of:
> [image: delta.png]
> I also don't know where I got [delta] from, it doesn't seem to have a help
> patch associated with it.
> anyways, replacing [delta] with the above gives the same result.
> but I'm starting to see why...
> Tim
>
> btw: this fixed my 'problem':

[line]
|
[change]
|
[delta]

gr,
Tim


>
>> gmadr
>> IOhannes
>>
>>
>> ___
>> 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

Re: [PD] line: grain rate and delta

[tim vets]

2010/10/21 IOhannes zmölnig 

> On 10/21/2010 03:30 PM, tim vets wrote:
> > Hi all,
> > I'm a bit confused about the grain rate of [line]
> > the help says that 'the default grain rate is 20 ms'
> > however, when I connect a [delta] to a [line], it shows zero's,
> > while inserting a [speedlim 20] changes that.
> > also some other tests in attached patch.
> > can someone explain ?
>
> as matju already stated, [delta] is something, a lot of people
> (including me) do not know.
>
> assuming it is the same as:
> |
> [t b b]
> | |
> [timer]
> |
>
> then it "looks" like you get "0", whereas in reality you get:
> [20, 0( [*]
>
> the "20" shows up so incredibly short (and is then overwritten by "0",
> that you simply cannot see it.
> [print] usually allows you to track such things, as you not only see the
> last value, but the entire history.
>
> [*] why?
> when [line] receives a new target, it will immediately send out the
> start value, and then (in grain-time ms) the next value until it reaches
> the target value.
> in your case this translates to:
> - you generate the first number ("7") and send [7 20( to [line]
> - line will immediately output the current value ("0") and after 20ms it
> will output the next value ("7")
> - at the "same" time, you generate a new value ("9"), and send this to
> [line], which will immediately output the current value ("7").
>
> since both the start value and the target value are output at the same
> logical time, [timer] caluculates a time-difference of "0", which will
> be visible for the next 20ms.
>
>

the way I understood it, [delta] is the equivalent of:
[image: delta.png]
I also don't know where I got [delta] from, it doesn't seem to have a help
patch associated with it.
anyways, replacing [delta] with the above gives the same result.
but I'm starting to see why...
Tim



> gmadr
> IOhannes
>
>
> ___
> 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

Re: [PD] overdriven speaker

[Martin Schied]

 Hi!


Looking at power and air pressure - we don't have to care about them 
as long as we don't want to include thermal effects


Isn't the heat proportional to the mean power ? Then you just do [*~] 
with itself and then some kind of [rpole~] to account for the 
accumulation thereof. After that I don't really know what to do with that.
one could feed the output of this [rpole~] into a [*~] to the input 
signal (or at any place later, but then it has to be cared for the delay 
of the doppler vd~ too, so better do it first). The exact parameters can 
be found by experiments, but as written in an earlier mail the signal 
reduction can be up to 7dB (I would use slightly more). I don't have 
time right now, but maybe I'll experiment  later...



or nonlinearities of the air I think.


I don't know them at all. I've never heard of anyone taking them into 
account.
I think there aren't many too. The only case I can imagine and I heard 
of is for huge negative signals, where you can't go beyond 0 pascal of 
air pressure and the signal is clipped physically - but I doubt this 
ever happens in small speakers. Also I'm not sure if this only happens 
in compression speakers.


The pressure directly in front of the cone is related to the 
acceleration I think, but I'm not sure about that.


It has to : the speaker makes a sound by pushing and pulling on the 
air, and that changes the pressure.
yes, but it could also be seen in that way: the cone's travel compresses 
air in an enclosed volume. when the cone is at its travel peak (the 
acceleration is 0) the air is compressed at maximum. And I'm not sure if 
this is the case for a speaker in "free field" (not sure if that's the 
exact term) too. I know that there's something called radiation 
resistance - but I know nothing useful about it yet.


Can anybody confirm that? I think that's not trivial to answer 
anyways, because already 10cm farther from the speaker the pressure 
and air velocity are different.


It has to... the reason why you hear the sound and why sound has a 
speed, is because neighbouring pressure differences cause pressure 
differences to propagate. It's a second-order differential equation, 
as the position of air particles is proportional to their 
acceleration. The Laplacian of the wave function along x,y,z is 
proportional to the 2nd derivative of the wave function along t... I'd 
write it like :


  D[D[f,x],x] + D[D[f,y],y] + D[D[f,z],z] = D[D[f,t],t] / v²

Where v² is the square of the speed of sound.

With a slight coordinate change using imaginary numbers, you can see 
it as a Laplacian along x,y,z,t instead, in 4-dimensional spacetime, 
and the Laplacian is equal to zero. But that's only if the air is 
considered frictionless :)
sorry, I don't understand that equation I think (I'm not understanding 
difference equations very well in general) and also I have no idea of 
Laplacians until now (I'll read about it and maybe understand later)




Ah, that means that the mechanical amplitude (travel) of the wave is 
much smaller for treble than bass, is that right ?

exactly.

cheers
Martin

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

Re: [PD] line: grain rate and delta

[Mathieu Bouchard]

On Thu, 21 Oct 2010, Frank Barknecht wrote:

On Thu, Oct 21, 2010 at 11:11:12AM -0400, Mathieu Bouchard wrote:

Instead I used [b]-[fps, mode logical], is that what you mean ?


 [t b b]
 | |
 [timer]

would be a line-rate-check that doesn't require any externals. See attachement.


But this doesn't show what [fps, mode logical] does.

[fps] tells you how many bangs per second, as an average over each second 
(or other period of your choice), whereas if there's a pair of bangs every 
20 ms, your thing will always display 0, which is especially why I didn't 
use it. Well, it's not like [fps] is absolutely better : what's absolutely 
better is to use both tools at once, as this is how you get the most info 
about what's going on.


 ___
| Mathieu Bouchard -- Villeray, Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] line: grain rate and delta

[Frank Barknecht]

On Thu, Oct 21, 2010 at 11:11:12AM -0400, Mathieu Bouchard wrote:
> On Thu, 21 Oct 2010, tim vets wrote:
>
>> Hi all,I'm a bit confused about the grain rate of [line] the help says  
>> that 'the default grain rate is 20 ms' however, when I connect a 
>> [delta] to a [line], it shows zero's,  while inserting a [speedlim 20] 
>> changes that. also some other tests in attached patch. can someone 
>> explain ?
>
> Instead I used [b]-[fps, mode logical], is that what you mean ?

  [t b b]
  | |
  [timer]

would be a line-rate-check that doesn't require any externals. See attachement.

Ciao
-- 
 Frank BarknechtDo You RjDj.me?  _ __footils.org__


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

Re: [PD] line: grain rate and delta

[IOhannes zmölnig]

On 10/21/2010 03:30 PM, tim vets wrote:
> Hi all,
> I'm a bit confused about the grain rate of [line]
> the help says that 'the default grain rate is 20 ms'
> however, when I connect a [delta] to a [line], it shows zero's,
> while inserting a [speedlim 20] changes that.
> also some other tests in attached patch.
> can someone explain ?

as matju already stated, [delta] is something, a lot of people
(including me) do not know.

assuming it is the same as:
|
[t b b]
| |
[timer]
|

then it "looks" like you get "0", whereas in reality you get:
[20, 0( [*]

the "20" shows up so incredibly short (and is then overwritten by "0",
that you simply cannot see it.
[print] usually allows you to track such things, as you not only see the
last value, but the entire history.

[*] why?
when [line] receives a new target, it will immediately send out the
start value, and then (in grain-time ms) the next value until it reaches
the target value.
in your case this translates to:
- you generate the first number ("7") and send [7 20( to [line]
- line will immediately output the current value ("0") and after 20ms it
will output the next value ("7")
- at the "same" time, you generate a new value ("9"), and send this to
[line], which will immediately output the current value ("7").

since both the start value and the target value are output at the same
logical time, [timer] caluculates a time-difference of "0", which will
be visible for the next 20ms.

gmadr
IOhannes



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

Re: [PD] line: grain rate and delta

[Mathieu Bouchard]

On Thu, 21 Oct 2010, tim vets wrote:

Hi all,I'm a bit confused about the grain rate of [line] the help says 
that 'the default grain rate is 20 ms' however, when I connect a [delta] 
to a [line], it shows zero's,  while inserting a [speedlim 20] changes 
that. also some other tests in attached patch. can someone explain ?


What's this [delta] thing ? There are several externals with the same 
name, and none of them is named just [delta] in pd-extended.


Instead I used [b]-[fps, mode logical], is that what you mean ?

In your case, 20 ms is an edge case, because [line] is told to reset 
immediately, at the same logical time as it just output its second value 
of the ramp. If you try with 19.999 ms it's different already.


 ___
| Mathieu Bouchard -- Villeray, Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Loop point : a way to make it smooth?

[Pierre Massat]

Hi,

Just in case this could be useful to someone, here's what i've ended up
doing in order to reduce the click at the looping point :
- I decide of the length and the starting point of the loop in a table.
- Then i play the "sample" plus an extra X ms at the end using another
phasor object (at a frequency adjusted for the extra X ms).
- This gets written into another table, about twice as long, and the sound
is directly envelopped before the tabwrite~ object. The enveloppe is made
using an expr~ object and a cos shape for the fade-in / fade-out.
- The actual, definitive loop is play from this last table, using a phasor
that runs at half the speed of the original phasor, and which reads two
phase-inversed "copies" of the same loop in the table, plus the silent rest
of the table. This means that the loop is played once, and when it is X ms
far from the end the second, phase-inversed loop starts playing. While the
phase-inversed loop plays the second half of the table (which has to be
"const 0" 'ed beforehand) plays with no effect on the output. This is really
just cross-fading between two tables, only there only one table and there is
not need to program an actual cross-fader. This works backwards just fine.


My goal was to reduce the clicks in order to get nice drones using a voice
as a source. This technique work fine with fairly long cross-fade times
(above 20 or 30 ms). I'm quite happy with the result.
Then again, you're perfectly right about the difficulty of making a nice
loop. The fact that the click is removed doesn't garantee that the loop will
be percieved as smooth.

Cheers!

Pierre

2010/10/11 Lorenzo 

>  Original Message 
> Subject: Re: [PD] Loop point : a way to make it smooth?
> From: Andy Farnell 
> To: Pierre Massat 
> CC: pd-list@iem.at
> Date: 10/10/2010 09:48 PM
>
>> Ah yes, I see the constraint,
>> well, what kind of source material is it?
>>
>> There's the zigzag (forward and back) method that
>> always seems to work well with textures and pad
>> like sounds. Have you tried that?
>>
>> Andy
>>
>> On Sun, 10 Oct 2010 21:32:21 +0200
>> Pierre Massat  wrote:
>>
>>
>>
>>> I think i know what you mean. The problem here is that it has to be live
>>> somehow. I don't how they do it in live loopers like the ones some
>>> singers
>>> use on stage.
>>> Thanks for your reply anway!
>>>
>>> 2010/10/10 Andy Farnell
>>>
>>>
>>>

 There's a simple way to put this.

 There is an art to looping.


>>> Some hints which can be useful both with the source material and the
> looping algorithm (but as Andy says much depends on the source):
> - zeros: the start and end of the loop should ideally be a zero (or be
> exactly the same number). Some sound editors (like mhwaveedit on linux) will
> find zero-crossings for you. Another way to go might be "cross-fade" at the
> start and end of the loop: that is have a small fade-in at the beginning and
> a short fade out at the end, but results vary a lot.
> - Finding the right "period" for the loop, on some sounds you'll want
> something very short on some pretty long
> - Avoid looping "attacks" part, for example of a piano sample avoid all the
> part at the beginning and loop only when the sound "stabilises"
>
>
> Lorenzo
>
>  It should be possible in a simple sound editor.

 You might find the best way (to save time)
 rather than spending dozens of hours to
 improve the technicalities of your looping code,
 is to give it to someone who is great
 at making loops who will do it in 20 seconds.

 It's also worth saying that it's very much about
 the source material. Some things are just not
 loopable in the way you think they might/should
 be. It takes a lot of practice to find out
 and hear immediately what needs doing.

 Andy



 On Sun, 10 Oct 2010 20:55:00 +0200
 Pierre Massat  wrote:



> Hi all!
>
> I've made a looping patch for a friend who needs to create a musical
>
>
 piece


> for her school. She's complaining about the fact that she hears when
> the
> sample loops back to it's beginning. I tried to envelop it using a
> table
>
>
 to


> control the volume which just ramps up from 0 to 1 during X ms (X being
> adjustable), outputs 1 during most of the sample except for the last X
> ms
> where it ramps back down. The ramps are not linear, they have sort of
> an
> inverse square shape. This doesn't really do the trick.
> I've been thinking of writing the sample to 2 tables, one delayed by
> the
> length of the sample minus X ms, so that i can play both tables and
>
>
 switch


> between the two to avoid having to bring the volume to 0 at one point.
>
>
 The


> sample needs to be X ms longer.
> Is there another way to go? I've been doing some research on the web,
> but
>

Re: [PD] reverb in pd

[saint]

+1 on ben saylor's partconv~ - works excellently.

arm yourself with the free acousticas IR's...
http://www.acousticas.net/World/IRs/AcousticasM7.zip

of the $3,500 bricasti m7 unit...
http://www.bricasti.com/m7.html

...and you'll not go back to algorithmic reverbs again.

or just get some balloons and record your own!

(grab those IR's soon as it seems acousticas have gone out of business. took me 
a few attempts to check but the link is working.)


  

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

[PD] line: grain rate and delta

[tim vets]

Hi all,
I'm a bit confused about the grain rate of [line]
the help says that 'the default grain rate is 20 ms'
however, when I connect a [delta] to a [line], it shows zero's,
while inserting a [speedlim 20] changes that.
also some other tests in attached patch.
can someone explain ?
Thanks,
Tim
#N canvas 221 114 334 216 10;
#X obj 37 92 line;
#X msg 37 70 \$1 20;
#X obj 37 26 metro 20;
#X obj 37 5 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1
;
#X obj 37 136 delta;
#X floatatom 37 159 5 0 0 0 - - -;
#X floatatom 73 159 5 0 0 0 - - -;
#X obj 37 48 random 120;
#X obj 108 115 speedlim 20;
#X obj 108 135 delta;
#X floatatom 108 159 5 0 0 0 - - -;
#X obj 188 116 line 0 20;
#X obj 188 135 delta;
#X floatatom 188 161 5 0 0 0 - - -;
#X obj 248 135 delta;
#X floatatom 248 161 5 0 0 0 - - -;
#X obj 248 116 line 0 200;
#X connect 0 0 6 0;
#X connect 0 0 4 0;
#X connect 0 0 8 0;
#X connect 1 0 0 0;
#X connect 1 0 11 0;
#X connect 1 0 16 0;
#X connect 2 0 7 0;
#X connect 3 0 2 0;
#X connect 4 0 5 0;
#X connect 7 0 1 0;
#X connect 8 0 9 0;
#X connect 9 0 10 0;
#X connect 11 0 12 0;
#X connect 12 0 13 0;
#X connect 14 0 15 0;
#X connect 16 0 14 0;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] soft-edging with multiple projectors/GEM

[Jack]

Le jeudi 21 octobre 2010 à 12:01 +0200, cyrille henry a écrit :
> 
> Le 21/10/2010 11:37, cyrille henry a écrit :
> > hello,
> >
> > i don't have a ready made solution, but once you have a FB, nothing
> > should be very complex.
> >
> > unless i miss the complex part of the problem.
> >
> > if i've got 5 min later tonight, i'll try to make a soft_edge shader
> > that can deal with everything...
> unless jack did it before me ;-)
Yep, i did something similar with my last game PdTron ;)
But i have no time today to work on this new problem...
++

Jack


> 
> >
> > cyrille
> >
> >
> > Le 21/10/2010 11:11, IOhannes m zmoelnig a écrit :
> >> On 2010-10-21 10:45, cyrille henry wrote:
> >>> hello,
> >>>
> >>> one solution is to render your scene in a big framebuffer.
> >>> (if you use 3 screen of 1024x768, and a 100 pixel overlap, then you need
> >>> a 3x1024-2x100 pixel wide framebuffer)
> >>>
> >>> then render this frambuffer as a texture on 3 rectangle, using
> >>> pix_coordinate in order to keep only the desire part of the image.
> >>> the black fade can be made with shader or texture as you prefer.
> >>>
> >>
> >> afaik (being somewhat involved in the project), this is not really
> >> peter's problem.
> >> he is already rendering into a big framebuffer.
> >>
> >> the question is rather, whether someone has a ready-made solution for
> >> displaying the image on multiple overlapping projectors, that they want
> >> to share. (if it is simple enough, it could go into the Gem/examples/...
> >> think of all the fame)
> >>
> >> the last solution we used for that (on 8 overlapping projectors), had a
> >> proprietary license and could only be setup by the developers... so we
> >> are looking for something more simple and open.
> >>
> >> fgmasdr
> >> IOhannes
> >>
> >>
> >> PS: note the slight change in wording in my email, from "peter" in the
> >> beginning to "we" in the end. it's somewhat unintentional :-)
> >>
> >>
> >>
> >>
> >> ___
> >> 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
> >
> 
> ___
> 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

Re: [PD] soft-edging with multiple projectors/GEM

[cyrille henry]

Le 21/10/2010 11:37, cyrille henry a écrit :

hello,

i don't have a ready made solution, but once you have a FB, nothing
should be very complex.

unless i miss the complex part of the problem.

if i've got 5 min later tonight, i'll try to make a soft_edge shader
that can deal with everything...

unless jack did it before me ;-)



cyrille


Le 21/10/2010 11:11, IOhannes m zmoelnig a écrit :

On 2010-10-21 10:45, cyrille henry wrote:

hello,

one solution is to render your scene in a big framebuffer.
(if you use 3 screen of 1024x768, and a 100 pixel overlap, then you need
a 3x1024-2x100 pixel wide framebuffer)

then render this frambuffer as a texture on 3 rectangle, using
pix_coordinate in order to keep only the desire part of the image.
the black fade can be made with shader or texture as you prefer.



afaik (being somewhat involved in the project), this is not really
peter's problem.
he is already rendering into a big framebuffer.

the question is rather, whether someone has a ready-made solution for
displaying the image on multiple overlapping projectors, that they want
to share. (if it is simple enough, it could go into the Gem/examples/...
think of all the fame)

the last solution we used for that (on 8 overlapping projectors), had a
proprietary license and could only be setup by the developers... so we
are looking for something more simple and open.

fgmasdr
IOhannes


PS: note the slight change in wording in my email, from "peter" in the
beginning to "we" in the end. it's somewhat unintentional :-)




___
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



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

Re: [PD] soft-edging with multiple projectors/GEM

[IOhannes m zmoelnig]

On 2010-10-21 11:37, cyrille henry wrote:
> hello,
> 
> i don't have a ready made solution, but once you have a FB, nothing
> should be very complex.
> 
> unless i miss the complex part of the problem.

it's not a complicated problem.
the most complicated part is the calibration to the actual projection space.


fmgasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] soft-edging with multiple projectors/GEM

[cyrille henry]

hello,

i don't have a ready made solution, but once you have a FB, nothing should be 
very complex.

unless i miss the complex part of the problem.

if i've got 5 min later tonight, i'll try to make a soft_edge shader that can 
deal with everything...

cyrille


Le 21/10/2010 11:11, IOhannes m zmoelnig a écrit :

On 2010-10-21 10:45, cyrille henry wrote:

hello,

one solution is to render your scene in a big framebuffer.
(if you use 3 screen of 1024x768, and a 100 pixel overlap, then you need
a 3x1024-2x100 pixel wide framebuffer)

then render this frambuffer as a texture on 3 rectangle, using
pix_coordinate in order to keep only the desire part of the image.
the black fade can be made with shader or texture as you prefer.



afaik (being somewhat involved in the project), this is not really
peter's problem.
he is already rendering into a big framebuffer.

the question is rather, whether someone has a ready-made solution for
displaying the image on multiple overlapping projectors, that they want
to share. (if it is simple enough, it could go into the Gem/examples/...
think of all the fame)

the last solution we used for that (on 8 overlapping projectors), had a
proprietary license and could only be setup by the developers... so we
are looking for something more simple and open.

fgmasdr
IOhannes


PS: note the slight change in wording in my email, from "peter" in the
beginning to "we" in the end. it's somewhat unintentional :-)




___
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

Re: [PD] soft-edging with multiple projectors/GEM

[IOhannes m zmoelnig]

On 2010-10-21 10:45, cyrille henry wrote:
> hello,
> 
> one solution is to render your scene in a big framebuffer.
> (if you use 3 screen of 1024x768, and a 100 pixel overlap, then you need
> a 3x1024-2x100 pixel wide framebuffer)
> 
> then render this frambuffer as a texture on 3 rectangle, using
> pix_coordinate in order to keep only the desire part of the image.
> the black fade can be made with shader or texture as you prefer.
> 

afaik (being somewhat involved in the project), this is not really
peter's problem.
he is already rendering into a big framebuffer.

the question is rather, whether someone has a ready-made solution for
displaying the image on multiple overlapping projectors, that they want
to share. (if it is simple enough, it could go into the Gem/examples/...
think of all the fame)

the last solution we used for that (on 8 overlapping projectors), had a
proprietary license and could only be setup by the developers... so we
are looking for something more simple and open.

fgmasdr
IOhannes


PS: note the slight change in wording in my email, from "peter" in the
beginning to "we" in the end. it's somewhat unintentional :-)



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] soft-edging with multiple projectors/GEM

[cyrille henry]

hello,

one solution is to render your scene in a big framebuffer.
(if you use 3 screen of 1024x768, and a 100 pixel overlap, then you need a 
3x1024-2x100 pixel wide framebuffer)

then render this frambuffer as a texture on 3 rectangle, using pix_coordinate 
in order to keep only the desire part of the image.
the black fade can be made with shader or texture as you prefer.

cyrille


Le 21/10/2010 00:34, n...@petervenus.de a écrit :

Hello!
Well, the softedge/overlap is quite useful in installations, since projectors 
sometimes have the bad habit of moving slightly, even when installed as proper 
as possible. If i do it Hard edged, meaning that the borders of the single 
images are exactly edge to edge this would lead to a gap between the 
pictures.the triplehead is just the solution to make a really wide image with 
3beamers, but doesn´t give me a solution for that particular problem, at least 
as far as i know.
regards, peter

-Ursprüngliche Nachricht-
Von: "Pagano, Patrick"
Gesendet: 21.10.2010 00:21:20
An: "n...@petervenus.de" , "pd-list@iem.at"
Betreff: RE: [PD] soft-edging with multiple projectors/GEM

Why do you need overlap if you are going to use a triplehead2Go?

-Original Message-
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of 
n...@petervenus.de
Sent: Wednesday, October 20, 2010 5:58 PM
To: pd-list@iem.at
Subject: [PD] soft-edging with multiple projectors/GEM

Hello List!

I have a question regarding the work with multiple projectors:
I am looking for solution within Pd/Gem to process the output in the GEMwindow
in a way, that i can work with a TripleHead2Go fullscreen and
to be able to set up the 3 Projectors with an overlap.

I know that there are some Hardware solutions, but far away of being affordable.

regards,
Peter

___
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


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