Re: [PD] Understanding the mechanics of rebuilding Pd's DSP graph

[Jonathan Wilkes via Pd-list]

Hi William,In practice, I'm not sure how inefficient they are.  Pd already has 
[switch~] for situations where some 
subpatch doesn't need to compute audio.
-Jonathan
   

 On Monday, November 23, 2015 1:58 PM, William Huston 
 wrote:
 

 > what qualifies as a "complex orphaned network"?

and [osc~] with no wires is the most trivial example of an 
orphaned tilde object. There is no need to add  it to the
DSP graph or compute audio for such. 

An orphaned (tilde) network is created when I connect two orphaned 
tilde objects together.

> how do you determine whether a dsp-object has I/O?

A tilde object is "active" (not orphaned) when its output is connected to 
any object which stores computed audio in memory, or sends audio 
external to PD,  like [dac~], [tabwrite~], or [writesf~].  

(OK-- externals become tricky, as PD's DSP compiler needs to understand
wither the external object sends audio outside PD, such as across
a network, or stores audio in memory)

A [throw~] / [catch~] network is orphaned if the output of [catch~]
is connected to an orphaned tilde network. 

These kinds of orphans (at least for PD vanilla objects) 
should be easy to detect if it is true as Jonathan says,
that there is a single DSP graph for each running instance of PD,
since they can be determined by examining the netlist alone. 
The reason I'm asking this is because since moving to a Raspberry Pi-based 
setup,
I'm trying to optimize my code for performance, since there is definitely a 
CPU budget on a Pi which is easily exceeded. 

I want to understand whether orphaned tilde objects are part of
the DSP graph, and steal cycles? or are they harmless? 



On Mon, Nov 23, 2015 at 1:18 PM, IOhannes m zmölnig  wrote:

On 11/23/2015 06:31 PM, William Huston wrote:
>
> *What about a complex "orphaned network" containing various tilde objects?*
>

what qualifies as a "complex orphaned network"?
how do you determine whether a dsp-object has I/O?


mfds
IOhannes


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





-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)

___
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] Understanding the mechanics of rebuilding Pd's DSP graph

[IOhannes m zmölnig]

On 11/23/2015 07:56 PM, William Huston wrote:
>> what qualifies as a "complex orphaned network"?
[...]
> 
> A tilde object is "active" (not orphaned) when its output is connected to
> any object which stores computed audio in memory, or sends audio
> external to PD,  like [dac~], [tabwrite~], or [writesf~].
> 
> (OK-- externals become tricky, as PD's DSP compiler needs to understand
> wither the external object sends audio outside PD, such as across
> a network, or stores audio in memory)

(does [hip~] store audio in memory?)

how is Pd supposed to know "this"?

the problem with all this is, that the entire scheme for saving CPU
cycles will be screwed if you there is a single object in your
to-be-orphaned network of which you don't know whether it has
"side-effects" (as in I/O; but also any other side-effect) or not.

> A [throw~] / [catch~] network is orphaned if the output of [catch~]
> is connected to an orphaned tilde network.
> 
> These kinds of orphans (at least for PD vanilla objects)
> should be easy to detect 

since Pd allows an external to override built-in classes, you don't even
know whether a sole unconnected [osc~] object does not phone home.

(though you probably can still find out whether any given object is
constructed from an external or "built-in")

in any case, the suggestion boils down to maintaining a "whitelist" of
objects-without-sideeffects, which is fragile at best.

> I want to understand whether orphaned tilde objects are part of
> the DSP graph, and steal cycles? or are they harmless?

yes. no (not in your sense).

if you are concerened about orphaned objects stealing CPU cycles, delete
them from your patch. this way they are *guaranteed* to not take any CPU
(nor memory), even with the most naive scheduler.
also: Pd has [switch~] to turn off parts of a DSP-graph (even if it is
not orphaned!).

gfmadsr
IOhannes



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] Understanding the mechanics of rebuilding Pd's DSP graph

[IOhannes m zmölnig]

On 11/23/2015 06:31 PM, William Huston wrote:
> 
> *What about a complex "orphaned network" containing various tilde objects?*
> 

what qualifies as a "complex orphaned network"?
how do you determine whether a dsp-object has I/O?


mfds
IOhannes



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] numberboxes range

[Lorenzo Sutton]

On 22/11/2015 23:20, Simon Iten wrote:

thanks!

i don’t really like the look of number2, it takes too much space.


Just for reference for future readers of the mailing list: it *is* 
possible to resize number2 and change many aesthetic properties both 
from the properties dialog and with messages.


Lorenzo.



anyhow, here is how i did it in my patch (which also needed simultaneous 
control with a numberbox and a slider and only ints)





On 22 Nov 2015, at 22:26, Christof Ressi  wrote:

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” 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://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] ICLI 2016: Call for Papers, Performances and Projects

[thor]

The Third International Conference on Live Interfaces

Call for Proposals

The third International Conference on Live Interfaces will be held on June 29th 
- July 3rd 2016 at the University of Sussex in Brighton, UK. The conference 
will bring together people working with live interfaces in the performing arts, 
including music, the visual arts, dance, puppetry, robotics or games.

The conference website: http://www.liveinterfaces.org

The conference scope is highly interdisciplinary but with a focus on expressive 
interface technologies for performance. Topics of liveness, immediacy, presence 
(and tele-presence), mediation, collaboration and timing or flow are engaged 
with and questioned in order to gain a deeper understanding of the role that 
contemporary media technologies play in human expression.

We wish to host work that will create a space of multiplicity, in order to 
investigate how disciplinary concerns inform different but overlapping 
approaches to interface design. The conference consists of paper presentations, 
performances, interactive installations, poster demonstrations, a doctoral 
colloquium and workshops. Works engaging with the principles and assumptions 
governing interaction design, including perspectives from art, philosophy, 
product design, and engineering are especially welcome.

We invite submissions that address critical and reflective approaches to key 
themes in the design and use of live interfaces. A wide range of approaches are 
encouraged by people from all possible backgrounds. The submission categories 
are the following:

Papers

5-8 pages. We are interested in submissions that address the conference topics 
listed below. The papers must consist of an original contribution to the field 
of artistic interfaces for live performance, describe its context, and 
demonstrate a rigorous research methodology. Paper authors may additionally 
present their work in the demo session.

Posters/Demos

3-6 pages. These are shorter artistic demonstrations of work or concepts. Space 
will be provided for posters and tables for demoing work. A link to an online 
video is required for posters and demos.

Doctoral Colloquium

2-6 pages describing current work. The doctoral colloquium will be an 
opportunity for researchers to present their work and meet other doctoral 
students in related fields, to discuss current research and approaches to 
practice-based research, and receive guidance from more experienced 
researchers. The day will include a session of short presentations in the 
morning, a symposium in the afternoon, and a short workshop in live interfaces 
in the early evening, finishing with food and drinks in the Digital Humanities 
Lab.

Performances, Installations and Workshops

2-4 pages. Proposals should clearly articulate how the work or workshop 
develops the design, use or conceptualisation of live interfaces as related to 
one or more of the conference themes and should comprise: a) A description of 
the work (including duration), b) an image (where appropriate), c) a link to 
online examples of the work, d) a 150-word biography for each collaborator, and 
e) a technical rider (with stage layout, audiovisual setup, and equipment to be 
provided by the venue). Daytime and evening performances will be in concert 
halls on campus, and club performances will be in two live music venues in 
Brighton. Please indicate what setting would best suit the work. Installation 
proposals should include description of the space and set-up time required. 
Workshops proposals should specify the duration and number of people that can 
be accommodated. Workshops and installations will be located in spaces across 
the University of Sussex campus.

Technical specifications of venues are available on request.

The proceedings will be published online in collaboration with REFRAME Books 
(MFM, University of Sussex). They will be Open Access, with Creative Commons 
attribution, and with an ISBN number. Each individual paper will receive a 
Digital Object Identifier (DOI).

We are looking forward to receive your submission!

The ICLI 2016 team


-

Conference Themes

- New Performance Interfaces: prosthesis, extensions
- Human Computer interaction: human-machine relationships
- Automata, non-humans, AI: autonomy in artistic performance
- Space, sound, installations: performing with installations
- Theory, Digital Arts, Culture: Interface theory
- Computer games, game theory: gameplay as performance art
- Audiovisual and multimodal works: multimodal performances

Topics

Topics include, but are not restricted to:

- New interfaces for musical expression 
- Non-musical performance interfaces 
- Multimodal and multisensory media 
- Augmented stage technologies 
- Audiovisual performance 
- Biophysical sensors 
- Brain-computer interfaces 
- Artificial intelligence and ALife in interfaces 
- Notation for new interfaces 
- Live coding in music, video, 

Re: [PD] numberboxes range

[Miller Puckette]

As a workaround you can simply force values into the range and send them
back to the box via a "set" message.  It's not exactly the same (since it will
also "correct" numbers typed in which the range setting doesn't) but might
be OK or even better for making interfaces with varying ranges.

cheers
Miller

On Sun, Nov 22, 2015 at 09:46:58PM +0100, Simon Iten wrote:
> 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://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] numberboxes range

[Simon Iten]

that’s kind of what i did here. even with state saving…

cheers


functionchanger.pd
Description: Binary data


> On 23 Nov 2015, at 14:50, Miller Puckette  wrote:
> 
> As a workaround you can simply force values into the range and send them
> back to the box via a "set" message.  It's not exactly the same (since it will
> also "correct" numbers typed in which the range setting doesn't) but might
> be OK or even better for making interfaces with varying ranges.
> 
> cheers
> Miller
> 
> On Sun, Nov 22, 2015 at 09:46:58PM +0100, Simon Iten wrote:
>> 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://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]

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 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 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
>> with the 512-pt table and linear interpolation.
>>
>>
>>
>> ___
>> 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?

[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 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 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
>>> with the 512-pt table and linear interpolation.
>>>
>>>
>>>
>>> ___
>>> 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?

[Robert Esler]

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 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 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
>>> with the 512-pt table and linear interpolation.
> 
> 
> ___
> 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] Understanding the mechanics of rebuilding Pd's DSP graph

[William Huston]

Got it. Thanks.

On Mon, Nov 23, 2015 at 2:47 PM, IOhannes m zmölnig  wrote:

> On 11/23/2015 07:56 PM, William Huston wrote:
> >> what qualifies as a "complex orphaned network"?
> [...]
> >
> > A tilde object is "active" (not orphaned) when its output is connected to
> > any object which stores computed audio in memory, or sends audio
> > external to PD,  like [dac~], [tabwrite~], or [writesf~].
> >
> > (OK-- externals become tricky, as PD's DSP compiler needs to understand
> > wither the external object sends audio outside PD, such as across
> > a network, or stores audio in memory)
>
> (does [hip~] store audio in memory?)
>
> how is Pd supposed to know "this"?
>
> the problem with all this is, that the entire scheme for saving CPU
> cycles will be screwed if you there is a single object in your
> to-be-orphaned network of which you don't know whether it has
> "side-effects" (as in I/O; but also any other side-effect) or not.
>
> > A [throw~] / [catch~] network is orphaned if the output of [catch~]
> > is connected to an orphaned tilde network.
> >
> > These kinds of orphans (at least for PD vanilla objects)
> > should be easy to detect
>
> since Pd allows an external to override built-in classes, you don't even
> know whether a sole unconnected [osc~] object does not phone home.
>
> (though you probably can still find out whether any given object is
> constructed from an external or "built-in")
>
> in any case, the suggestion boils down to maintaining a "whitelist" of
> objects-without-sideeffects, which is fragile at best.
>
> > I want to understand whether orphaned tilde objects are part of
> > the DSP graph, and steal cycles? or are they harmless?
>
> yes. no (not in your sense).
>
> if you are concerened about orphaned objects stealing CPU cycles, delete
> them from your patch. this way they are *guaranteed* to not take any CPU
> (nor memory), even with the most naive scheduler.
> also: Pd has [switch~] to turn off parts of a DSP-graph (even if it is
> not orphaned!).
>
> gfmadsr
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] band limited (anti-alias) techniques

[Alexandre Torres Porres]

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-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?

[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 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 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
> with the 512-pt table and linear interpolation.
>
>
>
> ___
> 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] band limited (anti-alias) techniques

[Matt Barber]

There's also the band-limited pulse wave (Dirichlet kernel oscillator),
like gbuzz in csound. See attached.

On Mon, Nov 23, 2015 at 9: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-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
>


gbuzz~-help.pd
Description: Binary data


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

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

[Christof Ressi]

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-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?

[Robert Esler]

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 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 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
>> with the 512-pt table and linear interpolation.

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

Re: [PD] Understanding the mechanics of rebuilding Pd's DSP graph

[William Huston]

> what qualifies as a "complex orphaned network"?

and [osc~] with no wires is the most trivial example of an
orphaned tilde object. There is no need to add  it to the
DSP graph or compute audio for such.

An orphaned (tilde) network is created when I connect two orphaned
tilde objects together.

> how do you determine whether a dsp-object has I/O?

A tilde object is "active" (not orphaned) when its output is connected to
any object which stores computed audio in memory, or sends audio
external to PD,  like [dac~], [tabwrite~], or [writesf~].

(OK-- externals become tricky, as PD's DSP compiler needs to understand
wither the external object sends audio outside PD, such as across
a network, or stores audio in memory)

A [throw~] / [catch~] network is orphaned if the output of [catch~]
is connected to an orphaned tilde network.

These kinds of orphans (at least for PD vanilla objects)
should be easy to detect if it is true as Jonathan says,
that there is a single DSP graph for each running instance of PD,
since they can be determined by examining the netlist alone.

The reason I'm asking this is because since moving to a Raspberry Pi-based
setup,
I'm trying to optimize my code for performance, since there is definitely a
CPU budget on a Pi which is easily exceeded.

I want to understand whether orphaned tilde objects are part of
the DSP graph, and steal cycles? or are they harmless?



On Mon, Nov 23, 2015 at 1:18 PM, IOhannes m zmölnig  wrote:

> On 11/23/2015 06:31 PM, William Huston wrote:
> >
> > *What about a complex "orphaned network" containing various tilde
> objects?*
> >
>
> what qualifies as a "complex orphaned network"?
> how do you determine whether a dsp-object has I/O?
>
>
> mfds
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Understanding the mechanics of rebuilding Pd's DSP graph

[William Huston]

This is an enormously helpful discussion.
Just reading it in-depth now.
I think this should be summarized for inclusion into an FAQ.

I have some circuit design experience (many years ago).
I worked with netlists for Spice and other circuit simulators.

My first big program in C (1989?) was a program which
traversed a Spice deck (a linked list) and among other things,
found "orphaned networks" which didn't go anywhere.
It's a network which ultimately has no input and no outputs.

There is no need to electrically simulate such orphans
(this was in the 1980s when computers were mainframes
and time was really expensive), and there is no need to
make these into silicon. So such circuits are "optimized out"
(deleted.)




*My question is, does PD compute audio for an orphaned [osc~] with no
leads?*

*What about a complex "orphaned network" containing various tilde objects?*

*Are these computed? Or optimized out during compilation?*

What I've heard here from Jonathan is,
"adding any tilde object recreates the DSP graph".

So just placing an [osc~] with no wires recalculates the graph?
The would seem like a waste.

Furthermore-- this can even be improved. If I take an [osc~] and connect
a wire to an object which is part of an active DSP graph (not orphaned),
then we clearly need to recompile.

However, if I connect the [osc~] to an "orphaned network" (no I/O),
then this does not need to recompile the graph.

I imagine there must be a PD agent which looks at the objects you've just
instantiated
and decides whether the DSP graph should be recompiled.

Is there any room for improvement here?

Thanks,
BH





On Tue, Sep 22, 2015 at 11:19 PM, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> wrote:

> Does [soundfiler] rebuild the dsp graph on read, or only if the -resize
> flag
> is used?  If its the latter then you can just set the right array size
> ahead of time.
> Then if you still get dropouts you'll know it's the blocking i/o doing it.
>
> -Jonathan
>
>
>
> On Tuesday, September 22, 2015 10:50 PM, Matt Barber 
> wrote:
>
>
> There's nothing wrong per se with resizing an array -- but there are good
> reasons not to do it while a patch is running after a [tab*] object has
> referred to it. I have myself only noticed audio dropouts when I'm resizing
> a table with soundfiler; I thought it must have been a disk-access
> bottleneck (soundfiler runs synchronously, yes?), but it would make sense
> if it in very large patches that a resize triggering a DSP recalc could do
> it. Though, then wouldn't adding any tilde object do the same?
>
> On Tue, Sep 22, 2015 at 4:00 PM, Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at> wrote:
>
> In C, what's the overhead of having function_call(return array->x_size)
> instead
> of array->x_size inside a perform routine?
>
> If that's not significant, it seems like it'd be better to over-allocate
> the array at creation/resize time and report the requested size to the
> user.  That way reallocation (and dsp-rebuilding) is only necessary if
> there's a substantial size change, or if the array is used by an external
> that uses the old API.
>
> That's certainly more difficult to do than just rebuilding the graph on
> every resizing.  But to me it's preferable to telling new users, "Here's how
> to resize an array, which is a central feature for using objects like
> [tabplay~] and
> 'Put' menu arrays and [soundfiler], but in reality don't use it because
> [[explanation of Pd's implementation details go here]]."
>
> -Jonathan
>
>
> On Tuesday, September 22, 2015 12:05 PM, Roman Haefeli 
> wrote:
>
>
> On Sun, 2015-09-20 at 22:19 +0200, IOhannes m zmölnig wrote:
> > On 09/17/2015 11:55 PM, Roman Haefeli wrote:
> >
> > > Is the time it takes to recalculate the graph only dependent on the
> > > number of tilde-objects running in the current instance of Pd? If so,
> is
> > > that a linear correlation? 10 times more tilde-objects means it takes
> 10
> > > times as long to recalculate the graph?
> >
> > [skipping those]
>
> Simple tests suggests that the relation is linear. But maybe this
> depends on the kind of graph? What I tested: I created 500 audio
> processing abstractions dynamically and then I measured the time it
> takes to send 'dsp 0, dsp 1' to pd. I did the same test again with 1000
> instances and time doubled.
>
> > > Why is resizing tables so much slower, when tilde-objects are
> > > referencing it? I noticed that even resizing very small tables can be a
> > > cause for audio drop-outs. I wonder whether 'live-resizing' should be
> > > avoided altogether.
> >
> > because the table-accessing objects will only check whether a table
> > exists and of what size it is) when the DSP graph is re-calculated.
> > this is a speed optimization, so those objects don't need to check the
> > table existance/size in each signal block.
> > the way how it is implemented is, that a table is marked as "being used
> > in DSP processing" by a