Re: [PD] oscillators (osc~ / cycle~) not working well in FM?

[IOhannes m zmoelnig]

On 2015-11-25 12:37, Roman Haefeli wrote:
> I fully support your opinion in this debate. If I'd be in charge, I'd
> fix it right away.

+1

if you are doing glitch - and relying on a bug in a software to get
those nifty sounds *is* glitch -, then you shan't complain if bugs get
fixed¹.

and of course: Pd is Open Source.
if you cannot live without any given bug, fork the source and unfix the
problem.
or just use an old version of Pd that still inhibits the problem.

fgmasdr
IOhannes

¹ hey, why doesn't Pd crash any more? my entire performance relied on
that...



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

Re: [PD] oscillators (osc~ / cycle~) not working well in FM?

[Alexandre Torres Porres]

> I think (...) the correct thing to do is to correct it but
> provide back compatibility

Everybody happy!

2015-11-25 14:31 GMT-02:00 Miller Puckette :

> Sorry not to jump in before... I think in the case of this particular
> design flaw,
> the correct thing to do is to correct it but provide back compatibility
> (as I
> did earlier with hip~ and inlet~).  It's quite possible nobody will ever
> care but it
> would be there in case someone did.
>
> cheers
> Miller
>
> On Wed, Nov 25, 2015 at 04:25:49PM +0100, IOhannes m zmoelnig wrote:
> > On 2015-11-25 12:37, Roman Haefeli wrote:
> > > I fully support your opinion in this debate. If I'd be in charge, I'd
> > > fix it right away.
> >
> > +1
> >
> > if you are doing glitch - and relying on a bug in a software to get
> > those nifty sounds *is* glitch -, then you shan't complain if bugs get
> > fixed¹.
> >
> > and of course: Pd is Open Source.
> > if you cannot live without any given bug, fork the source and unfix the
> > problem.
> > or just use an old version of Pd that still inhibits the problem.
> >
> > fgmasdr
> > IOhannes
> >
> > ¹ hey, why doesn't Pd crash any more? my entire performance relied on
> > that...
> >
>
>
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] oscillators (osc~ / cycle~) not working well in FM?

[Miller Puckette]

Sorry not to jump in before... I think in the case of this particular design 
flaw,
the correct thing to do is to correct it but provide back compatibility (as I
did earlier with hip~ and inlet~).  It's quite possible nobody will ever care 
but it
would be there in case someone did.

cheers
Miller

On Wed, Nov 25, 2015 at 04:25:49PM +0100, IOhannes m zmoelnig wrote:
> On 2015-11-25 12:37, Roman Haefeli wrote:
> > I fully support your opinion in this debate. If I'd be in charge, I'd
> > fix it right away.
> 
> +1
> 
> if you are doing glitch - and relying on a bug in a software to get
> those nifty sounds *is* glitch -, then you shan't complain if bugs get
> fixed¹.
> 
> and of course: Pd is Open Source.
> if you cannot live without any given bug, fork the source and unfix the
> problem.
> or just use an old version of Pd that still inhibits the problem.
> 
> fgmasdr
> IOhannes
> 
> ¹ hey, why doesn't Pd crash any more? my entire performance relied on
> that...
> 



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


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

Re: [PD] searching the email archive for common words

[Julian Brooks]

Good stat

On 25 November 2015 at 23:56,  wrote:

> I would like to re-post the below mail regarding the search feature of
>> the mailing list archive. I am sure everyone here agrees that the list
>> archive is one, if not the only one,
>>
>
> Would like to point the second resource with plenty of valuable info on pd:
> http://forum.pdpatchrepo.info/
>
> Marketing stats:
> 600k pages views / month
> 15k unique visitors / month
> 750 posts / month
>
> Cheers~
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Advice on bonk~ with bass guitar

[Miller Puckette]

I think this will be very hard to do reliably.  I can't get perfectly reliable
attacks for a guitar, even with the strings separated.  I heard a rumor that
some neural net thing might work better than bonk~ for strings but never saw
it myself.

cheers
Miller

On Wed, Nov 25, 2015 at 02:31:37PM +, Ed Kelly wrote:
> Hi List,
> I'm trying to use bonk~ to segment bass guitar. I want to capture every note. 
> Does anyone have any advice to optimize the settings of bonk~ for this?
> Cheers,Ed
>  Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, 
> for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music 
> notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ 

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


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

Re: [PD] searching the email archive for common words

[Peter P.]

Dear list,

I would like to re-post the below mail regarding the search feature of
the mailing list archive. I am sure everyone here agrees that the list
archive is one, if not the only one, of the most comprehensive
collections of Pd knowledge that comes from more than a decade of
fruitful discussions and insight know-how. It would be great if there
was a way to reliably search this valuable data.

* Peter P.  [2015-04-20 18:25]:
> Hi list,
> 
> the biggest wealth of information about Pd might lie in the mailing list
> archives at http://lists.puredata.info/pipermail/pd-list/
> Searching these archives for words which appear very often, such as
> "extended" "Gem" etc will return messages from the search algorithm,
> that these words are excluded from the results as there are too many
> occurrences. That might make sense, but renders the usability of the
> search algorithm very useless for certain requests.
> 
> Could there be a way to improve this? Or are there already other methods
> of searching the mailing list archive, besides downloading the raw
> 700+MB archive?
> 
> thanks,
> P

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

Re: [PD] [hdplay~] problem

[Dan Wilcox]

Ah, if so it’d be nice to have that noted in the help patch ;)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Nov 21, 2015, at 4:00 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: IOhannes m zmölnig >
> Date: November 20, 2015 at 10:15:53 AM MST
> To: pd-list@lists.iem.at 
> Subject: Re: [PD] [hdplay~] problem
> 
> 
> On 11/20/2015 07:07 AM, Dan Wilcox wrote:
>> Judging from the [readsf~] help patch, [readsf~] takes two optional 
>> arguments:
>> 
>> 1. number of channels
>> 2. buffer size per channel in bytes
>> 
>> I think argument 2 might be worth investigating ...
> 
> it is, but you might discover that it is about something else:
> [readsf~] reads the data from harddisk in a separate thread. the "buffer
> size" defines how much the reading thread can read ahead of the playback.
> 
> gfmrdsa
> IOhannes

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

Re: [PD] searching the email archive for common words

[puredata]

I would like to re-post the below mail regarding the search feature of
the mailing list archive. I am sure everyone here agrees that the list
archive is one, if not the only one,


Would like to point the second resource with plenty of valuable info on pd:
http://forum.pdpatchrepo.info/

Marketing stats:
600k pages views / month
15k unique visitors / month
750 posts / month

Cheers~



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

[PD] A "Ramp" object?

[Alexandre Torres Porres]

Howdy, looking for an object that "breaks a continuous signal into linearly
interpolated segments with specific durations". It's not like
[rampsmooth~], it's like "Ramp" in SC. Feeding white noise to it would be
like rand~ or noisi~

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

Re: [PD] GEM: pushing gem output to v4l2loopback device

[jamal crawford]

Hi Benja, List

big massive thanks for the reply works like a charm! :)

cheers
~/.jc
>
> you can grab what is happening in Gem window with pix_snap
and then use pix_record with a message like : [codec v4l2, file
/dev/video20, record 1< if /dev/video20 is the virtual v4l2 device you
want to use attached a small exemple extracted from a bigger project, so
it can't work alone, adapt it to your needs you can also send any Gem
chain directly to pix_record and to a virtual device without pix_snap

++ b

Le 20/11/2015 13:00, jamal crawford a écrit :
>> hey list

i wonder how do you push gem output to v4l2loopback device.
gem_recordV4L2.so is loaded, but i cant seem to find any info on
the plugin.
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] A "Ramp" object?

[Matt Barber]

​Check these out.​ I think what you're looking for is inside of noisei~.
Sorry for no helpfile, but you can make it easily enough. Inlet controls
frequency of new value generation (audio rate is possible).

On Wed, Nov 25, 2015 at 2:44 PM, Alexandre Torres Porres 
wrote:

> Howdy, looking for an object that "breaks a continuous signal
> into linearly interpolated segments with specific durations". It's not like
> [rampsmooth~], it's like "Ramp" in SC. Feeding white noise to it would be
> like rand~ or noisi~
>
> cheers
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


noise4~.pd
Description: Binary data


noiseh~.pd
Description: Binary data


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

Re: [PD] Font Options

[Py Fave]

on my system font is  DejaVu Sans Mono
i find it readable


GEM is an extension of pd , made for opengl
 graphics.
it drives a separate window from pd's interface.


it's in pd-extended, or available here

https://puredata.info/downloads/gem

2015-11-25 3:04 GMT+01:00 Thomas WillNot <1137...@acadiau.ca>:

> Thanks for the response!
>
> What is GEM window and how do I use it?
> Thomas
>
> "Py Fave"  wrote in message
> news:caaqhdpdb3gjcnxs_8+jg45awinp4dvxzzh6ncnwv+tdhivf...@mail.gmail.com...
> sorry i replied too fast .
>
> my answer was for text in GEM window.
>
> 2015-11-20 17:00 GMT+01:00 Py Fave :
>
>> check for FSAA message
>>
>> to send to gemwin before creation
>>
>> arguments depend on the platform you use and on graphics card
>>
>>
>>
>>
>>
>> 2015-11-19 18:02 GMT+01:00 Thomas WillNot <1137...@acadiau.ca>:
>>
>>> Hello,
>>>
>>> I am new to Pure Data, and am having trouble with text display. The
>>> default
>>> display settings are a very small font size and font smoothing is not
>>> handled properly, so if I have my system settings using the "standard"
>>> font
>>> smoothing method, which is to use normal greyscale smoothing at large
>>> point
>>> sizes, then this is not respected. From some research and messing
>>> around, I
>>> have found that the default font is DejaVu sans, which is illegible at
>>> small
>>> sizes and not nice looking or readable unless scaled to 24 point, so I
>>> deleted it from my computer and it's now falling back to Courier thank
>>> goodness.
>>>
>>> I saw there are some font-related command-line options since there is
>>> only a
>>> menu for font size. I have no idea how to run these however. I am
>>> running Pd
>>> on Microsoft Windows.
>>>
>>> In the mean time, I have font smoothing completely disabled system wide,
>>> but
>>> I'd like to turn the standard font smoothing back on again because it is
>>> really essential for a lot of Web sites using nonstandard fonts these
>>> days.
>>>
>>> Using Pd-Extended (since it doesn't bold the font automatically unlike
>>> vanilla Pd) I'd like to change the font to something nice and readable
>>> like
>>> Fixedsys!
>>>
>>> Thanks,
>>>Thomas
>>>
>>>
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>>
> --
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] oscillators (osc~ / cycle~) not working well in FM?

[Alexandre Torres Porres]

We can all create any external we like i guess, but this is a matter of
discussing the workings and the update/fix of internal/vanilla objects such
as cos~ osc~ and tabosc4~

most of us we're surprised with this behaviour and think they should be
updated/fixed. I personally strongly don't think it is reasonable to create
new alternates in vanilla for this.

I do emphatically believe they should just be fixed and updated in the
vanilla package of objects.

creating not known externals that are not part of any major package release
and no one really knows about may not have significant impact... let us
reason, Pd Extended is no more... this means that (more than ever) vanilla
issues should be treated as vanilla issues and not as an issue that could
have a workaround in an extended package or with an external...

Unless you're asking why miller isn't thinking about creating new objects.
In which case only he could answer, but it is my understanding that vanilla
is a very compact set of objects, and newer objects are not to pop up that
easily, so don't expect it.

cheers

2015-11-25 6:06 GMT-02:00 Simon Iten :

> why not just create a new object with correct symmetry and no dc? call it
> sin~ or cycle~ or whatever…
> i don’t think a compromise is a good way.
>
> On 25 Nov 2015, at 00:01, Robert Esler  wrote:
>
>
> Okay, here is a compromise.  What may be a fix, or a new feature.  It
> changes the oscillator to double precision, but costs a few more CPU cycles
> in the process.  This seems to keep things more accurate. Attached is the
> source and a compiled version for OS 10.10+ and this is the git repository
> if anyone is interested.
>   But I still say let’s keep osc~ as is and just add the double precision
> as an alternative.
>
> https://bitbucket.org/resler/osc2/overview
>
> Best,
> Rob
> 
>
> On Nov 24, 2015, at 10:39 AM, Jonathan Wilkes  wrote:
>
> Does anyone have an example of a working patch that depends on the
> current behavior?
>
> -Jonathan
>
>
>
> On Tuesday, November 24, 2015 9:52 AM, Alexandre Torres Porres <
> por...@gmail.com> wrote:
>
>
> > It's not that hard to add microscopic DC
> > if that's what you want
>
> I almost raised that up :) and it's easier than trying to fix it every
> time.
>
> I've lived with osc~ for over a decade, but it's like I finally found its
> dirty secret bug. Had I not found it I'd still be ok with it, but had I
> found this it years ago I'd have brought it up and asked for a fix.
>
> I think it's pushing it to compare legacy analog hardware with their
> signature sounds (which would mostly come down to filters, not sine waves)
> to an imprecise and easily fix digital code - it's not like it's the secret
> formula for digitally emulating the moog filter or something - it's just
> bad.
>
> Don't be afraid of changes and fixes, not sure what children's book teach
> us that lesson, but there might or ought to be one.
>
> cheers
>
> 2015-11-24 3:18 GMT-02:00 Matt Barber :
>
> ​Right, there are good reasons to want that behavior, but should it be the
> default in a program that aspires to be "deterministic"? ​It's not that
> hard to add microscopic DC if that's what you want, or add a tiny, tiny bit
> of low-pass-filtered noise to you oscillator to make it act more like
> acoustic gear.
>
> The other thing is, Pd isn't only an audio application. The quality of an
> oscillator is context dependent, and "how does it sound" isn't always the
> most important consideration. "Can I predict how this will behave?" is the
> more important question much of the time.
>
> On Mon, Nov 23, 2015 at 11:31 PM, Robert Esler 
> wrote:
>
> I think you just found one of the nuances I’m referencing.  Think of
> analog gear, none of the sinusoids are anywhere near perfect, yet we still
> like how they sound.
> We’ve known about these issues of microscopic DC, phasing, etc of unit
> generators for a long time.   I recall an old pd thread explaining how
> [osc~] is working:
> http://music.columbia.edu/pipermail/music-dsp/2004-november/061991.html
> Moreover, we’ve all lived with [osc~] for what, about 15-20 years?  It’s
> legacy code.
>  I’m probably being so adamant because I’ve been reading the "Ugly
> Duckling" to my daughter, but aren’t children’s stories also lessons in
> computer synthesis too?
>
>
> On Nov 23, 2015, at 9:05 PM, Alexandre Torres Porres 
> wrote:
>
> moreover, I really doubt there's any particular nuance that comes out of
> this... or that a fix would break it. All I know is that it's preventing FM
> patches from achieving stable waveforms as they should.
>
> 2015-11-24 0:31 GMT-02:00 Matt Barber :
>
> I usually agree in cases like these, but a sinusoid oscillator with
> built-in DC is not the expected behavior in most any synthesis environment.
> Notice how everyone in this thread was genuinely surprised by this 

Re: [PD] band limited (anti-alias) techniques

[cyrille henry]

Le 24/11/2015 18:21, David Medine a écrit :

Välimäki and Houvilainen have published  a number of articles about something 
called 'differentiated parabolic waveforms'. Basically, you square a digital 
sawtooth and put it through a one-zero differentiating filter (y(n) = x(n) - 
x(n-1)). What you get out is a slightly rounder (less aliasing) sawtooth. I've 
never actually tried this, but it looks pretty interesting and could easily be 
patched. Super simple.

The CMJ paper explains it in full detail. You might need a University-style 
subscription to get the actual PDF:
http://www.mitpressjournals.org/doi/pdf/10.1162/comj.2006.30.2.19
but the reference is:
Välimäki, Vesa, and Antti Huovilainen. "Oscillator and filter algorithms for virtual 
analog synthesis." /Computer Music Journal/ 30.2 (2006): 19-31.



if someone have access to this paper, i would love to have a copy.
cheers
c




On 11/23/2015 6:07 PM, Christof Ressi wrote:

I can think of at least two:

1) wavetables filled with sinesum/cosinesum (possibly blending between different 
wavetables according to frequency --> many partials for low pitches, few 
partials for high pitches)
2) transition tables (check out 3.audio.examples/J09.bandlimited)



Gesendet: Dienstag, 24. November 2015 um 02:30 Uhr
Von: "Alexandre Torres Porres"
An:"pd-list@lists.iem.at"  
Betreff: [PD] band limited (anti-alias) techniques

hi, I know about the oversampling + filtering technique, which you can patch 
it, but what are other techniques for creating band limited signals you people 
know (not only those you could do it as a pd patch)? Yes, I'm thinking about 
oscillators mostly.

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

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




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



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

Re: [PD] oscillators (osc~ / cycle~) not working well in FM?

[martin brinkmann]

On 24/11/15 18:39, Jonathan Wilkes via Pd-list wrote:
> Does anyone have an example of a working patch that depends on the current 
> behavior?

i would not be surprised if changing osc~ would break (or at least alter
the sound of) many patches which rely on fm and feedback etc.

bis denn!
martin

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

Re: [PD] oscillators (osc~ / cycle~) not working well in FM?

[Simon Iten]

why not just create a new object with correct symmetry and no dc? call it sin~ 
or cycle~ or whatever…
i don’t think a compromise is a good way.

On 25 Nov 2015, at 00:01, Robert Esler  wrote:
> 
> Okay, here is a compromise.  What may be a fix, or a new feature.  It changes 
> the oscillator to double precision, but costs a few more CPU cycles in the 
> process.  This seems to keep things more accurate. Attached is the source and 
> a compiled version for OS 10.10+ and this is the git repository if anyone is 
> interested. 
>   But I still say let’s keep osc~ as is and just add the double precision as 
> an alternative.  
> 
> https://bitbucket.org/resler/osc2/overview 
> 
> 
> Best,
> Rob
> 
> 
>> On Nov 24, 2015, at 10:39 AM, Jonathan Wilkes > > wrote:
>> 
>> Does anyone have an example of a working patch that depends on the 
>> current behavior?
>> 
>> -Jonathan
>> 
>> 
>> 
>> On Tuesday, November 24, 2015 9:52 AM, Alexandre Torres Porres 
>> > wrote:
>> 
>> 
>> > It's not that hard to add microscopic DC
>> > if that's what you want
>> 
>> I almost raised that up :) and it's easier than trying to fix it every time.
>> 
>> I've lived with osc~ for over a decade, but it's like I finally found its 
>> dirty secret bug. Had I not found it I'd still be ok with it, but had I 
>> found this it years ago I'd have brought it up and asked for a fix.
>> 
>> I think it's pushing it to compare legacy analog hardware with their 
>> signature sounds (which would mostly come down to filters, not sine waves) 
>> to an imprecise and easily fix digital code - it's not like it's the secret 
>> formula for digitally emulating the moog filter or something - it's just bad.
>> 
>> Don't be afraid of changes and fixes, not sure what children's book teach us 
>> that lesson, but there might or ought to be one.
>> 
>> cheers 
>> 
>> 2015-11-24 3:18 GMT-02:00 Matt Barber > >:
>> ​Right, there are good reasons to want that behavior, but should it be the 
>> default in a program that aspires to be "deterministic"? ​It's not that hard 
>> to add microscopic DC if that's what you want, or add a tiny, tiny bit of 
>> low-pass-filtered noise to you oscillator to make it act more like acoustic 
>> gear.
>> 
>> The other thing is, Pd isn't only an audio application. The quality of an 
>> oscillator is context dependent, and "how does it sound" isn't always the 
>> most important consideration. "Can I predict how this will behave?" is the 
>> more important question much of the time.
>> 
>> On Mon, Nov 23, 2015 at 11:31 PM, Robert Esler > > wrote:
>> I think you just found one of the nuances I’m referencing.  Think of analog 
>> gear, none of the sinusoids are anywhere near perfect, yet we still like how 
>> they sound.  
>> We’ve known about these issues of microscopic DC, phasing, etc of unit 
>> generators for a long time.   I recall an old pd thread explaining how 
>> [osc~] is working: 
>> http://music.columbia.edu/pipermail/music-dsp/2004-november/061991.html 
>> 
>> Moreover, we’ve all lived with [osc~] for what, about 15-20 years?  It’s 
>> legacy code.
>>  I’m probably being so adamant because I’ve been reading the "Ugly 
>> Duckling" to my daughter, but aren’t children’s stories also lessons in 
>> computer synthesis too?
>> 
>> 
>>> On Nov 23, 2015, at 9:05 PM, Alexandre Torres Porres >> > wrote:
>>> 
>>> moreover, I really doubt there's any particular nuance that comes out of 
>>> this... or that a fix would break it. All I know is that it's preventing FM 
>>> patches from achieving stable waveforms as they should.
>>> 
>>> 2015-11-24 0:31 GMT-02:00 Matt Barber >> >:
>>> I usually agree in cases like these, but a sinusoid oscillator with 
>>> built-in DC is not the expected behavior in most any synthesis environment. 
>>> Notice how everyone in this thread was genuinely surprised by this behavior.
>>> 
>>> On Mon, Nov 23, 2015 at 9:20 PM, Robert Esler >> > wrote:
>>> I would call this more of a feature than a bug that needs fixing.  I would 
>>> hope that [osc~] and [cos~] don't change, simply because many of us like 
>>> these little nuances.
>>>   If it is really bothersome then perhaps create a new version, but let’s 
>>> not change a legacy object.  A simple “fix” might break someone else’s 
>>> patch.
>>> 
>>> Just my opinion,
>>> -Rob
>>> 
 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 

Re: [PD] oscillators (osc~ / cycle~) not working well in FM?

[Roman Haefeli]

On Wed, 2015-11-25 at 08:27 -0200, Alexandre Torres Porres wrote:
> If dirtiness and imperfect is your secret spice in building beautiful
> and lively patches, you can still make it so, and there are several
> ways to do this... but preventing an oscillator from being accurate
> and in a completely arbitrary way at the expense of preventing a
> simple and common/regular FM patch to be built seems a bit too
> nonsensical IMO...

I fully support your opinion in this debate. If I'd be in charge, I'd
fix it right away.

This thread lead to an idea. I'm thinking of  a Pdesafinado - a slightly
out of tune Pd, that has all constants slightly wrong and some less
significant bits flipped in the floating point format and other little
imprecisions and deviations. It'll make totally new pieces out of all
your existing patches. 

I'd try it out for sure, if someone comes up with this ;-)

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Running TCL files in vanilla Window version.

[Mario Mey]

I would like to run PureData as similar to a standalone application. I 
would like to:


- Have all the files and dirs inside one dir (portable). No installation.
- Run a Pure Data patch in Windows with a batch file inside main dir.
- Use KIOSK-plugin to:
  - Hide Pd window
  - Have no menues
  - Avoid to enter in Edit Mode

I downloaded Pd version 0.46-7 compiled for Microsoft Windows (zip 
archive) (zip; 8 Megabytes) 
 from Miller's page, I 
want to use this version. I have some doubts:


- Where should I put KIOSK-plugin files? I repeat, I want the 
application not to be installed, I want a portable version. So, I would 
need to tell PureData a relative dir to get that plugin.
- Which files and dirs are necessary and which aren't? doc, tcl, src, 
portaudio, portmidi...? From extra I should only leave what I will need...


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

Re: [PD] Running TCL files in vanilla Window version.

[Lorenzo Sutton]

Hi.

On 25/11/2015 14:30, Mario Mey wrote:

I would like to run PureData as similar to a standalone application. I
would like to:
- Have all the files and dirs inside one dir (portable). No installation.


(On Windows) just unzip the the file in any directory. No need to 
install (I even had Pd run from usb sticks).



- Run a Pure Data patch in Windows with a batch file inside main dir.


Put the patch(es) in the ./bin dir (under the pd dir) and create a .bat 
(windows batch file) in that dire and add:


start pd.exe mypatch.pd

[...]

- Where should I put KIOSK-plugin files? I repeat, I want the
application not to be installed, I want a portable version.


If you put the two files kiosk-plugin.tcl and kiosk.cfg in the ./extra
(of course modify kiosk.cfg as needed)

Hope this helps

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

Re: [PD] oscillators (osc~ / cycle~) not working well in FM?

[Christof Ressi]

Totally agree in every point! [osc~] should definitely be fixed, for me there's 
no doubt about it. If this would, however, really break some patches 
(examples?), why not include a legacy version of [osc~] and make it possible to 
set the global behaviour via a Pd message - just like it's the case with 
[hip~]. 
 
 

Gesendet: Mittwoch, 25. November 2015 um 11:27 Uhr
Von: "Alexandre Torres Porres" 
An: "martin brinkmann" 
Cc: "pd-list@lists.iem.at" 
Betreff: Re: [PD] oscillators (osc~ / cycle~) not working well in FM?

I'd be really surprised if it'd "break" - that's a strong term.

 
Alter the sound a bit, maybe, sure, to a not desirable effect, maybe yes or 
maybe just not at all...
 
Now, conversely... any Frequency Modulation patch is really broken because it 
doesn't really work as it should!
 

Well, in the case of really wanting an imperfect oscillator, as has been said 
by Matt, it'd not be that hard to add microscopic DC to achieve such or 
whatever effect (maybe even more DC to add more noise/chaos). It's actually a 
common thing, I use that technique all the time... I add randomness/noise, 
offsets, whatever... if I wanna make it less perfect.
 
I really don't see the point of keeping a flawed code for a deterministic 
oscillator/generator that is meant to be more accurate than that in computer 
music systems, such as it is the case with Max and SuperCollider, to mention a 
couple of those - I could go on and test/mention others (Csound/Chuck) and also 
digital systems (Reaktor/whatever). 
 
I fail to see the reason why Pd would have to be the odd one out - that one 
which don't really have a nice and accurate oscillator if you need it. The one 
you can't really build a nice and stable FM patch, because, well, it just won't 
sit still.
 
If dirtiness and imperfect is your secret spice in building beautiful and 
lively patches, you can still make it so, and there are several ways to do 
this... but preventing an oscillator from being accurate and in a completely 
arbitrary way at the expense of preventing a simple and common/regular FM patch 
to be built seems a bit too nonsensical IMO...
 
I guess the best way to answer this question from Jonathan is just saying and 
showing you have a patch that really depends on it.
 
On the other hand, and on the other corner of the ring, there are FM patches 
which would actually rely on an improvement/fix of [osc~]. So, even if some 
such patches pop up, well, c'mon... nice FM patches seems a priority... 
because, again, you can just add, if you want, any dirtiness at your own taste 
in DC Offset, noisiness, whatever, and you can still restore or find out a new 
dimension to explore in your patches.
 
cheers
 
2015-11-25 7:37 GMT-02:00 martin brinkmann :On 
24/11/15 18:39, Jonathan Wilkes via Pd-list wrote:
> Does anyone have an example of a working patch that depends on the current 
> behavior?

i would not be surprised if changing osc~ would break (or at least alter
the sound of) many patches which rely on fm and feedback etc.

bis denn!
        martin

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

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

[PD] Advice on bonk~ with bass guitar

[Ed Kelly]

Hi List,
I'm trying to use bonk~ to segment bass guitar. I want to capture every note. 
Does anyone have any advice to optimize the settings of bonk~ for this?
Cheers,Ed
 Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, 
for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation 
for Pure Data, now with dynamics! http://sharktracks.co.uk/ ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list