[PD] GPG error on apt repo
These keys on sid: http://puredata.info/docs/faq/debian W: GPG error: http://apt.puredata.info sid Release: The following signatures were invalid: BADSIG 9F0FE587374BBE81 Hans-Christoph Steiner < h...@guardianproject.info> ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pdp 0.14.1
On 12/19/2013 09:49 AM, IOhannes m zmoelnig wrote: 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. quick questions: is scaf supposed to work on non-i386/amd64? no. scaf is hard-wired intel MMX assembly, so not compatible with other architectures. 3dp mostly works. Some known issues in corner cases (pdp/opengl/doc/examples): - example05.pd : multiple window render contexts causes crash i noticed that i cannot close a 3dp window. closing the patch will leave the window open, opening another 3dp patch will crash Pd. probably another manifestation of the problem with the context create/destroy/switch bug. fixing this is next on the list. thanks for the patches ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] A naive approach to bandlimiting
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-requ...@iem.at wrote: > From: Tony Hillerson > Subject: [PD] A naive approach to bandlimiting > Date: December 20, 2013 at 5:26:59 PM EST > To: pd-list@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.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-list Digest, Vol 105, Issue 30
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-requ...@iem.at wrote: > From: Tony Hillerson > Subject: [PD] A naive approach to bandlimiting > Date: December 20, 2013 at 5:26:59 PM EST > To: pd-list@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 > " 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.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] headroom in Pd
On 2013-12-20 16:55, Alexandre Torres Porres wrote: Hi there, where can I find info about headroom and clipping on Pd. Or can anyone tell me quickly how it goes? Does it always really clip over a maximum of 1, or is there some headroom? Does it depend on the audiocard or something? The soundcard will always clip above +1 and below -1, and sometimes even within those limits (if the interpolated waveform between samples goes over the limit). Pd will not clip internally, so you can calculate with larger numbers as long as you scale them back down before listening to them. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] A naive approach to bandlimiting
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 " 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] headroom in Pd
Hi there, where can I find info about headroom and clipping on Pd. Or can anyone tell me quickly how it goes? Does it always really clip over a maximum of 1, or is there some headroom? Does it depend on the audiocard or something? thanks ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] cartopol~ / poltocar~
I reported the bug as anonymous 2013/12/20 Alexandre Torres Porres > 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 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] cartopol~ / poltocar~
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 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] pd-aubio 0.3
Hi all! As some of you have noticed, a new version of aubio has been released a few days ago. aubio is a library of functions to analyze music signals, providing note onset detection, pitch detection, and beat tracking, amongst others. The previous release of aubio included the pd-aubio external, which now has its own package. Source tarball, signature and digest: http://aubio.org/pub/pd-aubio/pd-aubio-0.3.tar.bz2 http://aubio.org/pub/pd-aubio/pd-aubio-0.3.tar.bz2.asc http://aubio.org/pub/pd-aubio/pd-aubio-0.3.tar.bz2.md5 http://aubio.org/pub/pd-aubio/pd-aubio-0.3.tar.bz2.sha1 Git repository: git://git.aubio.org/git/pd-aubio/ http://git.aubio.org/?p=pd-aubio.git;a=summary Mirror on github: https://github.com/piem/pd-aubio To find out more about the latest aubio release: Post announcing aubio 0.4.0: http://aubio.org/news/20131217-1900_aubio_0.4.0 ChangeLog for aubio 0.4.0: http://aubio.org/pub/aubio-0.4.0.changelog Merry hacking! Paul ___ 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
Re: [PD] TCP/IP communication from the unix server to the Pure Data
Hello again, problem solved by adding -arch i386 to both command lines. Thank you, anyway Damiano On Dec 19, 2013, at 6:22 PM, Damiano wrote: > Martin Peach sympatico.ca> writes: > >> >> OK, I added two externals into svn at >> > http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mrpeach/serializer/ >> [b2f] will take four bytes and return a float, while [f2b] takes a float >> and outputs four bytes. (This is really easy in c...) >> Of course it only works if the floating-point format is the same at both >> ends. >> >> Martin > > Hi all, > I'm using OSx 10.8.5 on a macbook pro and pd-extended 0.42.5. I tried to > compile Martin's b2f.c from the terminal using these commands: > > cc -DPD -O2 -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused > -Wno-parentheses -Wno-switch -I ./ -o b2f.o -c b2f.c > > > cc -bundle -undefined suppress -flat_namespace -o b2f.pd_darwin b2f.o > > > And then copied the *.pd_darwin file to ~/Library/Pd/b2f. Unfortunately, the > resulting b2f.pd_darwin is not imported correctly by puredata. I get the > following error when trying to create the b2f object: > > /Library/Pd/b2f/b2f.pd_darwin: dlopen(/Library/Pd/b2f/b2f.pd_darwin, 10): no > suitable image found. Did find: > /Library/Pd/b2f/b2f.pd_darwin: mach-o, but wrong architecture > b2f > ... couldn't create > > > I used > lipo -info b2f.o > to check the architecture of the output file, but the answer looks OK: > > Non-fat file: b2f.o is architecture: x86_64 > > > Any suggestions? Has anybody tried to compile b2f.c or f2b.c in OSx? > > Thank you > -Damiano > > > ___ > 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] piano computer keyboard patch
thanks. I ended up using funbuf to assign the keys to the midi pitches, and make a piano layout of the computer keyboard. but I'll keep these examples around, for the next time. João Maybe you would be interested about trying attached gpiano abstraction Tested on pd-l2ork, this should be working on pd-extended thanks. for some reason it wasn't yet what I'm looking for. for now I used funbuff to assign computer keys to midi values. mtl/piano? https://github.com/patricksebastien/mtl ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
