Hi List,
An update to PDP:
http://zwizwa.be/pd/pdp/pdp-0.14.1.tar.gz
0.14.1:
Port SCAF MMX code to x86_64 ABI
Revive pdp_opengl (3dp)
Bugfixes
SCAF (Simple Cellular Automata Forth) is ported to x86_64 ABI. It still
uses the old MMX 64bit integer code which makes little sense on x86_64,
but at least it works.
3dp mostly works. Some known issues in corner cases
(pdp/opengl/doc/examples):
- example05.pd : multiple window render contexts causes crash
- example06.…
[View More]pd : bug in scaf CA grid -> texture conversion ?
The texture feedback also looks a little weird - not as I remember it.
Enjoy
Tom
_______________________________________________
Pd-announce mailing list
Pd-announce(a)iem.at
http://lists.puredata.info/listinfo/pd-announce
[View Less]
I would checkout rjlib and the s_osc~ which has bandlimited oscillators ... no need to reinvent the wheel. rjlib is vanilla so it will work fine with libpd.
Also, if you want the analog sound, the creb/moog~ external is kosher for the App store. I have it in PdParty.
On Dec 20, 2013, at 5:27 PM, pd-list-request(a)iem.at wrote:
> From: Tony Hillerson <tony.hillerson(a)gmail.com>
> Subject: [PD] A naive approach to bandlimiting
> Date: December 20, 2013 at 5:26:59 PM EST
> To:…
[View More] pd-list(a)iem.at
>
>
> Hey guys,
>
> I’m building an iOS and Android app with an “analog" synth component. I’m pretty inexperienced with the DSP world, and my math and theoretical understanding of things is pretty rudimentary. Because I’m building a mobile app, I feel like I need to build each of the components of the synth myself instead, to avoid issues such as those with the App store and the GPL.
--------
Dan Wilcox
@danomatika
danomatika.comrobotcowboy.com
[View Less]
I would checkout rjlib and the s_osc~ which has bandlimited oscillators ... no need to reinvent the wheel. rjlib is vanilla so it will work fine with libpd.
Also, if you want the analog sound, the creb/moog~ external is kosher for the App store. I have it in PdParty.
On Dec 20, 2013, at 5:27 PM, pd-list-request(a)iem.at wrote:
> From: Tony Hillerson <tony.hillerson(a)gmail.com>
> Subject: [PD] A naive approach to bandlimiting
> Date: December 20, 2013 at 5:26:59 PM EST
> To:…
[View More] pd-list(a)iem.at
>
>
> Hey guys,
>
> I’m building an iOS and Android app with an “analog" synth component. I’m pretty inexperienced with the DSP world, and my math and theoretical understanding of things is pretty rudimentary. Because I’m building a mobile app, I feel like I need to build each of the components of the synth myself instead, to avoid issues such as those with the App store and the GPL.
>
> I’ve built the oscillator array, now and I have something I’d like to run by this group. I understand enough of the problem of band limiting to know the ill effect to the sound, and that there are a few different approaches people take to solve it. I don’t quite understand enough of how these solutions work, though to know if there’s “a solution” that I should use. After thinking about the problem I tried the approach I lay out below, and I’d like feedback. Is it a naive way of solving the problem? Does it introduce other problems? Is it really inefficient? Here goes:
>
> I have nine tables, which I populate with a collection of geometric wave data using sinesum. Each table has fewer harmonics than the last. Then I use an array of [moses] objects to check the incoming MIDI note and call a "set <tablename>" on a [tabosc4~] before each note is played.
>
> I choose a table with fewer harmonics as the note gets higher, and the boundary is generally the B note in the next octave. So, to produce a sawtooth wave, I have a wavetable with 714 partials for MIDI notes 24 and below, 357 partials for MIDI 36 down to 25, 178 partials from MIDI 48 to 37, and so on until between 128 and 109 I use a table with a single sine wave.
>
> My naive understanding is that this approach is fairly efficient with CPU, but not efficient with memory. I believe it will let me have nice fat low-end notes, but should never have any aliasing as notes go higher in the register.
>
> Anyhow, I hope that was clear enough. What of this approach?
>
> --
> Tony Hillerson
--------
Dan Wilcox
@danomatika
danomatika.comrobotcowboy.com
[View Less]
Hey guys,
I’m building an iOS and Android app with an “analog" synth component. I’m pretty inexperienced with the DSP world, and my math and theoretical understanding of things is pretty rudimentary. Because I’m building a mobile app, I feel like I need to build each of the components of the synth myself instead, to avoid issues such as those with the App store and the GPL.
I’ve built the oscillator array, now and I have something I’d like to run by this group. I understand enough of the …
[View More]problem of band limiting to know the ill effect to the sound, and that there are a few different approaches people take to solve it. I don’t quite understand enough of how these solutions work, though to know if there’s “a solution” that I should use. After thinking about the problem I tried the approach I lay out below, and I’d like feedback. Is it a naive way of solving the problem? Does it introduce other problems? Is it really inefficient? Here goes:
I have nine tables, which I populate with a collection of geometric wave data using sinesum. Each table has fewer harmonics than the last. Then I use an array of [moses] objects to check the incoming MIDI note and call a "set <tablename>" on a [tabosc4~] before each note is played.
I choose a table with fewer harmonics as the note gets higher, and the boundary is generally the B note in the next octave. So, to produce a sawtooth wave, I have a wavetable with 714 partials for MIDI notes 24 and below, 357 partials for MIDI 36 down to 25, 178 partials from MIDI 48 to 37, and so on until between 128 and 109 I use a table with a single sine wave.
My naive understanding is that this approach is fairly efficient with CPU, but not efficient with memory. I believe it will let me have nice fat low-end notes, but should never have any aliasing as notes go higher in the register.
Anyhow, I hope that was clear enough. What of this approach?
--
Tony Hillerson
[View Less]
hi there, I once called for the attention that these objects were buggy, as
they were giving inverted values.
Anyway, since they were both screwed up in the same way, the conversion
back would inverted back and make everything alright, or at least sound
correct.
Well, for the pd extended 0.43 I see this has been corrected, at least for
the control data objects.
As for the signal objects, [cartopol~] was corrected, but not [poltocar~].
This means that it now can screw up your sound processing …
[View More]a lot and make
some patches - that were actually "ok" before - sound bad.
the way to work around this problem is to invert the imaginary part
(multiply it by -1) coming out of [poltocar~]
Cheers
[View Less]
Apparently [netclient] on the Pure Data side cannot receive nothing else
than ; delimited messages.
So the solution for the problem:
*My question is, is there a way to send something other than string
message to Pure Data, like byte-stream or serialized number stream? Can
Pure Data receive such messages?*
The solution is to use [tcpclient], it can receive byte-stream data.
Now I have another problem regarding the data read, on how to convert it
back to usable numbers.
From my UNIX …
[View More]server I am sending a structure
typedef struct {
int var_code;
int sample_time;
int hr;
float hs;
} phy_data;
Sample data might be 2 1000000 51 2000.56
When received and printed in Pure Data I get output like this:
>>>: 2 0 0 0 104 34 9 0 51 0 0 0 235 50 48 69
You can notice number 2 and number 51 clearly, I guess the others are
correct as well. Might be some network inversion of LSB/MSB.
*How can I get these numbers back to a usable format and get them in
separate variables?
*//Petar*
*
[View Less]
Hi all,
I remember a very old patch with a piano keyboard display that would allow users to play the computer keyboard as if it would be a piano. Does anyone know where that patch is, or if I didn't just dream it?
Thanks,
jmmmp