Malte Steiner a écrit :

I do something simular with wavetables in the spirit of PPG or Waldorf synthesizers (stepping through a bunch of single cycle waves), its great in combination with the moog~ filter and it sounded well on a concert yesterday. There are two windows applications out there which can generate wavetables and I managed to run them on my Linuxbox with Wine. Its the freeware Tranzilon

http://www.xs4all.nl/~avg/tranzilon/info.html

I didn't try this freeware, but it looks like very good, the info.html is explicitly show the fonctionning,then we could deduce how to proceed for doing something similar with this. Also I am not sure how one hundred of waveforms would be stored into the patch. Using one hundred of tables woild be the basic solution, but also a single table for storing them all could be enough. In all cases, DS will be usefull for manipulating waves by hand. Ciao, PC.

#N canvas 0 0 618 280 10; #X obj 85 115 noise~; #X text 121 13 waveshape morphing; #X obj 134 82 nbx 5 14 -1e+037 1e+037 0 1 empty empty Frequency 0 -6 0 10 -262144 -1 -1 1017 256; #X floatatom 131 183 5 0 0 0 - - -; #X obj 173 181 hsl 128 15 0 127 0 0 empty empty WaveShape -2 -6 0 8 -262144 -1 -1 0 1; #N canvas 0 0 450 300 (subpatch) 0; #X array $0-lfo3 10000 float 2; #X coords 0 1 10000 -1 100 50 1; #X restore 332 176 graph; #X obj 179 208 t b; #X obj 209 211 t b; #X obj 195 237 tabwrite~ $0-lfo3; #X msg 155 122 63; #X msg 157 103 0; #X msg 155 143 127; #N canvas 508 62 468 391 module3 0; #X obj 139 23 inlet~; #X obj 176 343 outlet~; #X obj 233 71 osc~; #X obj 232 50 / 100; #X obj 140 122 samphold~; #X obj 232 24 inlet; #X obj 283 23 inlet; #X obj 315 55 fade-morph 63 128; #X obj 176 234 +~; #X obj 176 267 +~; #X obj 324 106 fade-morph 0 126; #X obj 325 157 fade-morph -63 126; #X obj 242 160 *~ 0; #X obj 177 151 *~ 0; #X obj 234 209 *~ 1; #X text 327 36 Random; #X text 336 87 Square; #X text 335 136 Sinus; #X obj 252 264 t b; #X obj 220 144 -~; #X obj 216 120 <~ 0; #X obj 247 120 >~ 0; #X obj 248 295 tabwrite~ $0-lfo3-square; #X connect 0 0 4 0; #X connect 2 0 14 0; #X connect 2 0 20 0; #X connect 2 0 21 0; #X connect 3 0 2 0; #X connect 4 0 13 0; #X connect 5 0 3 0; #X connect 6 0 7 0; #X connect 6 0 10 0; #X connect 6 0 11 0; #X connect 6 0 18 0; #X connect 7 0 13 1; #X connect 8 0 9 0; #X connect 9 0 1 0; #X connect 10 0 12 1; #X connect 11 0 14 1; #X connect 12 0 8 1; #X connect 12 0 22 0; #X connect 13 0 8 0; #X connect 14 0 9 1; #X connect 18 0 22 0; #X connect 19 0 12 0; #X connect 20 0 4 1; #X connect 20 0 19 0; #X connect 21 0 19 1; #X restore 111 208 pd module3; #X msg 317 82 ; pd dsp 1; #X obj 319 47 loadbang; #X connect 0 0 12 0; #X connect 2 0 3 0; #X connect 3 0 12 1; #X connect 3 0 6 0; #X connect 4 0 7 0; #X connect 4 0 12 2; #X connect 4 0 8 0; #X connect 6 0 8 0; #X connect 7 0 8 0; #X connect 9 0 4 0; #X connect 10 0 4 0; #X connect 11 0 4 0; #X connect 12 0 8 0; #X connect 14 0 13 0;

Malte Steiner a écrit :

I didnt looked into your patch yet but usually these waveforms are stored in one table as one sample.

Oops, fortunately you didn't looked into the patch, there was, again, a missing abstraction which is attached. It's a kind of autorange but that outputs values between zero and one for a given pair of input range. This abstraction permits to slide between waveforms by adding them progressively

Your tabread object should run through one waveform at a time,

So the functionning seems different because my patch is about getting the average between to successive waveshapes, instead of passing from one to another without transition.

I have to look up how much bytes they are but assume 256, so it runs from 0 to 255 and to switch to another waveform you add n*256 where n is the waveformnumber.

Good, then the amount of samples won't get truncated with using one hundred of different waveforms.

http://en.wikipedia.org/wiki/Wavetable

thanks, PC.

Cheers,

Malte

#N canvas 0 0 339 233 10; #N canvas 29 318 179 311 fade-morph 0; #X obj 42 8 inlet; #X obj 41 267 outlet; #X obj 42 114 change; #X obj 41 245 /; #X obj 42 157 -; #X obj 109 50 $2; #X obj 127 118 / 2; #X obj 42 178 abs; #X obj 42 200 -; #X obj 42 222 abs; #X obj 42 135 - $1; #X obj 42 30 t a b; #X obj 80 72 + $1; #X obj 42 91 clip $1; #X connect 0 0 11 0; #X connect 2 0 10 0; #X connect 3 0 1 0; #X connect 4 0 7 0; #X connect 5 0 6 0; #X connect 5 0 12 0; #X connect 6 0 4 1; #X connect 6 0 3 1; #X connect 6 0 8 1; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 9 0 3 0; #X connect 10 0 4 0; #X connect 11 0 13 0; #X connect 11 1 5 0; #X connect 12 0 13 2; #X connect 13 0 2 0; #X restore 163 121 pd fade-morph; #X text 161 47 $2 = ending fade out; #X text 161 26 $1 = begining fade in; #X text 148 66 $2/2 = top level; #X text 86 44 inlet; #X text 72 189 outlet = value between 0 and 1; #X obj 163 94 inlet; #X obj 163 145 outlet; #X connect 0 0 7 0; #X connect 6 0 0 0;

On Sun, 2007-01-14 at 15:01 +0000, Claude Heiland-Allen wrote:

When writing it I found a bug in wrap~ in pd-0.40-2 from Miller's site:

sig~ 1 wrap~ print~ -> 0

as i would expect.

sig~ 0 wrap~ print~ -> 1

as i would expect, as well. where is the bug? am i missing something?

roman

Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

On Mon, 2007-01-15 at 05:51 +0000, Claude Heiland-Allen wrote:

Roman Haefeli wrote:

...

On Sun, 2007-01-14 at 15:01 +0000, Claude Heiland-Allen wrote:

...

When writing it I found a bug in wrap~ in pd-0.40-2 from Miller's site:

sig~ 1 wrap~ print~ -> 0

as i would expect.

...

sig~ 0 wrap~ print~ -> 1

as i would expect, as well. where is the bug? am i missing something?

wrap~-help says:

----8<---- wrap~ gives the difference between the input and the largest integer not exceeding it (for positive numbers this is the fractional part). ----8<----

largest integer not exceeding 0 is 0, or?

largest integer not exceeding X is X when X is an integer, or?

exactly, and since [wrap~] gives you the difference between the largest integer not exceeding X and X, it will always give you 0, when X is an integer. the output of [wrap~] is always => 0 and < 1.

it makes life simpler when

(x - (wrap~ x)) == x

when x is an integer, as there is no [int~] in Pd.

i can't quite follow, what you mean hear. you CAN use [wrap~] to build your own [int~] (see attached patch).

roman

On Mon, 2007-01-15 at 14:08 +0100, Frank Barknecht wrote:

Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:

...

i can't quite follow, what you mean hear. you CAN use [wrap~] to build your own [int~] (see attached patch).

Well, the problem is, that this will give you "-1" if you apply it to [sig~ 0], whereas int(0) is 0 as is the equivalent message algorithm using [wrap] (see attached again).

ah, i see. thank you for making this clear. obviously i cannot count to 1 ;-).

...

...

sig~ 0 wrap~ print~ -> 1

as i would expect, as well. where is the bug? am i missing

something?

of course, this looks also strange in my eyes. i was not reading carefully.

roman

___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

On 15/01/2007, at 11.49, Roman Haefeli wrote:

exactly, and since [wrap~] gives you the difference between the
largest integer not exceeding X and X, it will always give you 0, when X is an integer.

That's how i read it too. But following that: If 0 (zero) is an
integer (it normally is, right?), then the largest integer not
exceeding 0 is 0, and the difference is 0-0=0. Problem being that
wrap~ of the signal 0 gives 1, not 0.

I'd like to know too, as i find the description from the help patch
confusing (when the input is integers). As i understand what wrap~
does (again, on the integer domain), it's like a function f: Z ->
{0,1} where f(N)=0 and f(Z\N)=1 (where N is the numbers 1,2,3,.. and
Z is the numbers ...,-1,0,1,...).

the output of [wrap~] is always => 0 and < 1.

Again, i agree that from the description it would make sense if that
intact was the output domain. But it doesn't match the experience
using wrap~.

That said. Why does wrap~ of fx. the signal -0.99 return 0.00999999? and wrap~ of fx. -5.99 return 0.0100002?

It seems that the precision is low: if wrap~ outputs the difference with the signal and the greatest integer, not larger than it, for -0.99 it should return 0.01.

BTW, if one wants to get frac part of the signal, then with the current implementation of wrap~ (returning 1 for each non-positive integer)

[wrap~] | [wrap~]

should do the work: 0 for any integer and the frac part for any other number.

Sorry, "reply" instead of "reply all" again.

Well, it seemed impossible to me, but here what I found in d_math.c (pd 0.40.0 or something, I'm a bit lazy to look for version):

static t_int *sigwrap_perform(t_int *w) { float *in = *(t_float **)(w+1), *out = *(t_float **)(w+2); t_int n = *(t_int *)(w+3); while (n--) { float f = *in++; int k = f; if (f > 0) *out++ = f-k; else *out++ = f - (k-1); } return (w + 4); }

Here it definitely says: if f <= 0 then return f - ((int f) - 1) = f - (int f) + 1 = frac(f) + 1 which is 1 for each non-positive int, of course, and assumes float-to-int conversions (int k = f) take 'neares to zero' which seems a dangerous assumption for me (I guess, it should return frac(f) + 1, where 0<=frac<1 for each negative number; perhaps, some compiler flags fix it, it depends on compiler, but for integers the result is always 1). I think, the whole situation is worthy a bug report.