Apologies for x-posting--please consider sharing this announcement with
your colleagues/constituents.
I am pleased to announce the call for works (papers, posters,
installations, and performance works) for the upcoming Contemplative
Practices for the 21st Century University conference that wil
This should do it.
M
On Sun, Nov 22, 2015 at 10:36 PM, Alexandre Torres Porres
wrote:
> Did you make it work in a patch? if so, can you share it? :)
>
> Maybe someone could work on a "fix" on the source and send it to miller,
> perhaps this could be updated for the next version release (0.47).
Did you make it work in a patch? if so, can you share it? :)
Maybe someone could work on a "fix" on the source and send it to miller,
perhaps this could be updated for the next version release (0.47).
cheers
2015-11-22 19:32 GMT-02:00 Matt Barber :
> Yeah, so all that really needs to be done is
Nice to hear you got it working! :-) Would be really great if this gets fixed
in the source.
Gesendet: Sonntag, 22. November 2015 um 22:32 Uhr
Von: "Matt Barber"
An: "Roman Haefeli"
Cc: Pd-List
Betreff: Re: [PD] oscillators (osc~ / cycle~) not working well in FM?
Yeah, so all that really n
thanks!
i don’t really like the look of number2, it takes too much space.
anyhow, here is how i did it in my patch (which also needed simultaneous
control with a numberbox and a slider and only ints)
functionchanger.pd
Description: Binary data
> On 22 Nov 2015, at 22:26, Christof Ressi wrot
Yeah, so all that really needs to be done is to force symmetry by copying
the 0-pi phase inverted to the pi-2pi phase + guard points for [tabosc4~].
I did that and it's been stable for 3.5 hours. It wouldn't be too hard to
fix this in the Pd source; it would be a marked improvement to [osc~] even
w
Yes, at least for 'Number2' you can set all the properties via messages. For a
simple 'Number' I don't think so...
> Gesendet: Sonntag, 22. November 2015 um 21:46 Uhr
> Von: "Simon Iten"
> An: Pd-List
> Betreff: [PD] numberboxes range
>
> hi list,
>
> would it be possible to make the “range” o
hi list,
would it be possible to make the “range” of a numberbox settable via messages?
like with vsl etc?
or is there a way to set it (not via properties)?
cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, understood, i didn't see your attached patch from your first mail.
++
Jack
Le 22/11/2015 17:15, Roman Haefeli a écrit :
> On Sun, 2015-11-22 at 16:57 +0100, Jack wrote:
>> Why you don't use [text] to build a fifo abs ?
>
>
> One of the three
Hm, originally I was thinking this:[struct fifo float head float tail array a
fifo-datum]
[struct fifo-datum float flag float f symbol s]
for a fifo of single-atom messages.
But for a fifo of Pd messages I'm talking about this:[struct fifo float head
float tail array a fifo-datum]
[struct fifo-da
You'd store the number of elements in the list at the first index of a
fifo entry and the number of elements in the symbol or float just before
the data for each atom -- on read you'd accumulate the atoms of the list
and stop. The next index would be the number of elements in the next fifo
list en
I might be reading it wrong, but Matt's description sounds like a way to queue
atoms, not Pd messages.
With the "text" field of data structures it might be possible to add Pd
messages to that design-- that is, you could have a data structure array where
each element is a text field. But
Pd is
OK, subtracting out the DC is more stable, but still deteriorates after a
bit, since the exact value likely changes with frequency due to
interpolation. So the solution is going to have to be in writing the table.
We can do it in Pd but we're hampered by the six-digit limit on specifying
2pi direct
On Sun, 2015-11-22 at 16:24 +, Jonathan Wilkes wrote:
> Are you trying to add Pd messages to a queue of Pd messages, or create
> a fifo
>
> for atoms?
I was/am interested in a FIFO implementation for Pd messages of any size
(containing symbols and/or floats).
Why are you asking? Do you know
Are you trying to add Pd messages to a queue of Pd messages, or create a fifo
for atoms?
-Jonathan
On Sunday, November 22, 2015 11:17 AM, Roman Haefeli
wrote:
On Sun, 2015-11-22 at 16:57 +0100, Jack wrote:
> Why you don't use [text] to build a fifo abs ?
One of the three examples I
On Sun, 2015-11-22 at 10:44 +0100, volker böhm wrote:
> hi,
> i think the timbre change in the FM example is due to a less than ideal
> cosine wavetable which is used for osc~ (and cos~ etc.).
> the "cos_maketable(void)" in d_osc.c produces a waveform which is slightly
> asymmetric, i.e. it has a
On Sun, 2015-11-22 at 16:57 +0100, Jack wrote:
> Why you don't use [text] to build a fifo abs ?
One of the three examples I posted uses [text] as storage. While popping
is fast, adding messages to the buffer gets slower the more messages are
in the buffer. I was looking for an implementation that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Why you don't use [text] to build a fifo abs ?
++
Jack
Le 22/11/2015 09:47, Roman Haefeli a écrit :
> On Sun, 2015-11-22 at 01:47 -0500, Matt Barber wrote:
>> Your [fifo-list] is very much like [list-fifo] from list-abs,
>> which suffers from the p
... with inlet~ and outlet~ obviously
On Sun, Nov 22, 2015 at 9:59 AM, Matt Barber wrote:
> This means we should be able to subtract out the DC in PD itself, as a
> workaround. If it works, you could make an abstraction for modulating
> oscillator:
>
> [inlet]
> |
> [osc~ $1]
> |
> [-~ 2.65309
This means we should be able to subtract out the DC in PD itself, as a
workaround. If it works, you could make an abstraction for modulating
oscillator:
[inlet]
|
[osc~ $1]
|
[-~ 2.65309e-06]
|
[outlet]
Seems stable so far to me. I'll run it for an hour to see.
The correction for tabosc4~ wou
yes, this could easly be improved by not using phase accumulation to calculate
the wavetable and by using something a little closer to pi for the phase
increment.
something like this (i'm looking at cos_maketable(void) in d_osc.c):
float *fp, phase, phsinc = (2. * 3.1415926) / COSTABSIZE;
...
fo
Hmmm... so phaseincr is not as precise as it could be. And because phase is
incremented by phaseincr for every point of the wavetable, it is clear that
large wavetables are more asymmetric than short ones because the errors add up.
Still, a large wavetable done with cosinesum seems to be more pr
Ah, what kind of strikes me as odd is that in the routine garray_dofo it says:
double phase, phaseincr, fj;
...
phaseincr = 2. * 3.14159 / npoints;
Because phaseincr had been declared as double, Pi could have been written with
a lot more decimal places. Or am I missing something?
> Gesendet
>> the "cos_maketable(void)" in d_osc.c produces a waveform which is slightly
>> asymmetric, i.e. it has a tiny DC offset.
Thanks! That's exactly what I could observe when nulling [osc~] and [tabosc4~].
Is there a reason for the wavetable being slightly asymmetric?
Looking at the source code, c
hi,
i think the timbre change in the FM example is due to a less than ideal cosine
wavetable which is used for osc~ (and cos~ etc.).
the "cos_maketable(void)" in d_osc.c produces a waveform which is slightly
asymmetric, i.e. it has a tiny DC offset.
this in return, causes the timbre shift when us
>> I have to say I didn't see much improvement with 8192 point wavetable and
>> tabosc4~
In your patch you substituted the carrier but the problem is the modulator.
Once you use [tabosc4~] as the modulator, the drift is minimal (but it's still
there). Actually it doesn't matter if you use [os
On Sun, 2015-11-22 at 01:47 -0500, Matt Barber wrote:
> Your [fifo-list] is very much like [list-fifo] from list-abs, which
> suffers from the poor [list] performance. The message-box one also
> suffers from having to use lists to dequeue.
>
>
> I've thought of a way to do it using [list fromsymb
27 matches
Mail list logo
