Re: [PD] Paper about vcf~ implementation?

[i go bananas]

Hi, i recently coded it in more 'readable' c++ code.  Can share with you if
u want, i guess?

It's a "one pole complex filter", and miller has suggested previously on
this list that it is indeed basically a wrapper for the same code as the
cpole~ object, with some other stuff thrown in to calculate the
coefficients.
( https://lists.puredata.info/pipermail/pd-list/2014-07/107391.html )

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

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

[i go bananas]

as imperfect as Vanilla's lop~ / hip~ / vcf~ objects may be...i would
strongly argue against replacing them in the same namespace, as many old
patches rely on the sound they deliver.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] find array

[i go bananas]

If you're going to do dynamic patching anyway, then if you actually create
your arrays dynamically using a simple number system or something, you can
put those array names in a list or something, and then check that list.

On Thursday, August 25, 2016, Liam Goodacre  wrote:

> Is there any way of querying PD to find out if a given array exists? I'm
> thinking of a dynamic patching command that says "if this array doesn't
> already exist, then create it". Unfortunately, the "multiple array defined"
> message prints to the console, not an individual object.
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] vline~ in a patch with dsp off

[i go bananas]

Have noticed that vline~ still takes message inputs when the dsp in the
patch is switched off.  I can't really think of any situations where that
is useful.

The problem is, that new messages get added to the message list, making it
longer and longer as more messages are input.

Miller, would it be possible to disable message input when vline~ is in a
patch or subpatch where dsp is off?
At the moment, it needs to be done manually with spigots, etc.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] external with more than 6 inlets possible?

[i go bananas]

(sorry, just talking to myself here again)

actually, you don't need to copy the inlets into separate arrays.  Just
making a temp array for the outlets, writing to that in the main for loop,
and then copying that to the outlet buffer in its own for loop is
sufficient.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] external with more than 6 inlets possible?

[i go bananas]

Thanks Claude and Iohannes.

seems this is likely an issue with the recycled signals then...

i tried the method Claude suggested, and even with any tweak i could think
of, it's still not working.

Iohannes, what do you mean when you say:

"which signals get re-used is a function of the surrounding patch, and
unrelated to the creation order within the object's dsp-function."

???

Is there some sort of logic or rule to this?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] external with more than 6 inlets possible?

[i go bananas]

this seems to work:

  // loop through the 4 oscillators, adding the left to right:

  t_sample l[4];

  t_sample r[4];

  t_sample out[4];



  while (n--)

  {

for (int osc = 3; osc >= 0; osc--)

{

  l[osc] = *left[osc]++;

  r[osc] = *right[osc]++;

  out[osc] = l[osc] + r[osc];

}

for (int osc = 3; osc >= 0; osc--)

{

  *output[osc]++ = out[osc];

}

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

Re: [PD] external with more than 6 inlets possible?

[i go bananas]

oops, those weird for loops are just a throwback to something i tried that
didn't work.

normal ones work fine:  for (int osc = 0; osc < 4; osc++)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] external with more than 6 inlets possible?

[i go bananas]

I'm scratching my head wondering what's happening with an external i have
written.  The first 6 inlets work as expected, but not getting any response
from inlets 7 and 8.
I cut my code down as much as possible, and made a really simple external
which just adds signals and outputs the result, but still getting this same
behaviour.

In the howTo guide on writing externals, it mentions that an object can
only be given a maximum of 6 arguments, or else needing a GIMME, so i was
wondering if perhaps that 6 argument limit is somehow related here?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Wake up subpatches

[i go bananas]

pd is not good for things like images in the patch windows. i assume you're
using an external for this?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] multiple [send] arguments

[i go bananas]

yeah you could argue that there are many things that can be done more
simply by expanding pd's code base.

for loops come to mind as the most obvious example.  instead of using

[1024(
|
[until]
|
[f ] x [+ 1]

pd could just have a [for 1024] object.

bit it doesn't, because the is a way to do it without new objects.

this is good in my opinion.  It means when you are first learning pd, you
only have to learn a small number of objects.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] multiple [send] arguments

[i go bananas]

In this situation i'd prepend the message with a destination name.  Then
use [route] to filter those destination names in the receives.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How (Pd's) 'limitations' enhance creativity

[i go bananas]

you don't have a DAW, so you're not sitting there just arranging boxes on a
screen all day...err...hang on... bad example ;)

On Thu, Mar 3, 2016 at 12:28 PM, Matt Barber  wrote:

> ​"Gate" is a metaphor, so it seems to me you just need another metaphor
> for what's going on. The best one I've come up with so far is entirely
> inappropriate for most cases, but gets the point across: instead of a
> "gate," you might think of it as a safety on a firearm. You can load and
> unload it all you want but as long as the safety is on it won't fire.​
> Another one might be "sending supplies past the blockade." Or if you want
> to keep the "gate" metaphor, it might be "tossing your knapsack over before
> trying to get through." Or "meet me at the rendezvous; don't do anything
> without me – if I don't make it past security with the goods, you'll have
> to abandon the plan."
>
> The other thing about this particular dataflow representation is that cold
> inlets are themselves a kind of gate. That might make the end-run feel
> better.
>
> A third option you didn't mention would be using [value].
>
> On Wed, Mar 2, 2016 at 9:20 PM, Jonathan Wilkes 
> wrote:
>
>> > 3. Its visual austerity is a huge help to me in thinking clearly about
>> patching and dataflow. It's amazing how often a geometrically elegant
>> solution turns out to be an elegant solution full stop.
>>
>> Coincidentally, I was thinking about counterexamples to this today.
>>
>> Consider a gate:
>>
>> float
>> |
>> v
>> -o <- gate!
>> |
>> v
>> (copy of) float
>>
>> One of the problems with C is that you must take care both in your
>> conditions for
>> opening the gate, and in avoiding many subtle bugs through spacing,
>> scoping, etc.
>> that could cause the gate to become ineffectual.  Many of those subtle
>> bugs are visual--
>> I mean, your variable's state is just waiting to be perused by any
>> context inside the
>> function that's willing to read it.  It's amazing Linux works at all when
>> you consider
>> how few constraints there are on the code one must reason about.
>>
>> A dataflow language improves this by representing the gate as a visual
>> barrier.
>> You can't just blithely read "stuff" below the gate[1].  The gate has to
>> pass the data
>> down the line, and even if you made an additional connection from "float"
>> to something
>> below, you have to drag the line visually over the gate so that your
>> violation of
>> common sense and decency is visually obvious.
>>
>> But now we have a problem, because if we have anything more than "float"
>> that we
>> want to operate on below the gate, we have no way to read it.  There are
>> two possible
>> solutions to this:
>> 1) store copies of the data below the gate, so that you can read
>> them if you happen to be allowed through the gate.
>> 2) send some more expressive form of data like an object through the
>> gate, and pack
>> everything you want to have access to into that object.
>>
>> #1 is what I see in most patches (and what I end up patching when I just
>> need to get
>> something done).  But think about how that complicates the dataflow.  In
>> the gate
>> example it's especially apparent-- if you want to store some data below
>> the gate you
>> have to draw a line that does an end run around it to the right inlet of
>> a [float] below
>> the gate.  That  violates the very representation of a gate that the
>> visual language was
>> trying to provide for you.
>>
>> #2 pack your data into a list and use [route] as the gate.  This restores
>> visual clarity
>> at the expense of anonymous positional arguments.  So it works well for
>> routing a list
>> of, say, two or three values.  But not so well for a larger amount of
>> discrete data.  An
>> example of this downside would be a patch that does a good job of showing
>> where
>> a list flows or branches, but then seeing a big message box at the bottom
>> with something
>> like [voice $1-$3 $5 $2 $4(.  It's a real pain to debug and extend
>> patterns like that.
>>
>> I'd be interested to hear other approaches to this problem.
>>
>> -Jonathan
>>
>>
>>
>>
>>
>>
>>
>> On Wednesday, March 2, 2016 8:20 PM, Matt Barber 
>> wrote:
>>
>>
>> This is a great way to frame it, and it is indeed how I approach
>> composition as well. It sometimes helps to think of a piece as a solution –
>> maybe the only solution – to a set of constraints.
>>
>> Three limitations that I love in Pd off the top of my head:
>>
>> 1. The relatively small set of core objects really helps with programming
>> ingenuity, and in fact has made me think through some things that have been
>> helpful in other programming contexts. I love when someone throws down a
>> "this can't be done in vanilla" challenge; I've learned lots from thinking,
>> "OK, we'll see about that!"
>>
>> 2. The smallish set of objects also means that Pd is not a black box. It
>> does mean sometimes that you have to know what you're doing, but 

Re: [PD] Bela - Ultra-low-latency embedded audio platform

[i go bananas]

yes awesome!  was just asking around the other day if someone had something
like this.  will def check it out!  Matt

On Mon, Feb 29, 2016 at 8:35 PM, Chris  wrote:

> Hi Pd List!
>
> I thought I would share our lab's latest embedded DSP project that might
> be of interest to a lot of people on this list. We've made a new
> high-performance embedded platform called Bela (http://bela.io) which is
> designed for creating digital musical instruments and interactive audio
> systems. We've been developing this for the past two years, and just today
> we launched it on Kickstarter:
>
>
> https://www.kickstarter.com/projects/423153472/bela-an-embedded-platform-for-low-latency-interact
>
> The most important unique feature of Bela is that it has extremely low
> latency of less than 1 millisecond between action and sound, which is a lot
> faster than anything else out there. There are also some useful features
> for profiling sensors and a built-in browser-based development environment.
> Basically it is the platform I have always wanted for my own audio projects
> and instrument building, and now we're excited to be launching it to a
> broader community of musicians and engineers.
>
> The board doesn't run Pd directly, but patches can be compiled using Enzien
> Audio's Heavy compiler  - so you can address
> all sensor IO's from the patch.
>
> If you have a moment, it would be great if you can help spread the word!
> The project is open-source hardware and software, and the campaign is run
> through the university. This email is not intended as a sales pitch -- our
> goal is to build awareness, so if you know anyone who you think might be
> interested please pass it along. You can find more info and social media
> links below. Thanks a lot!
>
> Best wishes,
> Chris
>
>
> 
> Bela tech details:
>
> Bela is an open-source platform for high-performance, ultra-low-latency
> audio and sensor processing. It provides stereo audio in and out, onboard
> speaker amplifiers, 8 16-bit analog inputs and outputs, and 16 digital
> I/Os, all in a small self-contained package. Bela is based on the
> BeagleBone Black single-board computer which features a 1GHz ARM processor
> running Linux.
>
> Bela runs a custom audio environment which is capable of extremely small
> audio buffer sizes down to 2 samples, producing latency under 1
> millisecond. All the analog inputs and outputs are sampled automatically at
> audio rates, providing precise time alignment between sensors and audio. It
> features an on-board, browser-based IDE including an in-browser
> oscilloscope. It can be programmed in C++, or Pd patches can be compiled
> for the board using the Heavy Audio Tools from Enzien Audio. The result is
> musical instruments which are faster to develop and more responsive to use.
>
> Bela was developed in the Augmented Instruments Laboratory, a team of 8
> people which is part of the Centre for Digital Music at Queen Mary
> University of London. The Kickstarter campaign, which runs through 1 April,
> supports the production of the hardware. A variety of boards and kits are
> available with prices starting at £45, and the software and designs are
> already free to download.
>
> More info:
> http://bela.io
> http://twitter.com/BelaPlatform
> https://www.facebook.com/belaPlatform/
>
> ___
> 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] s~ & r~ with block size other than 64?

[i go bananas]

I would assume it's also slightly more efficient that pd doesn't have to
check the vector size when processing the s~ / r~ functions.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[i go bananas]

>real-time zero-crossing detection with sample-rate precision.

this is something that is super simple to implement.

it's like:

if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal < 0
|| previousIncomingSignal > 0) return 1;
else return 0;

i also don't understand why such an easy tool has never been put into
vanilla pd.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] one more filter

[i go bananas]

oops, ignore that comment about the lowpass and bandpass modes not
working.  It was my patching mistake.  sorry!
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] one more filter

[i go bananas]

I seem to get the exact same output when using either of the 2 lowpass
modes and the bandpass mode.  Only the highpass seems different.

On Mon, Feb 22, 2016 at 2:31 PM, i go bananas <hard@gmail.com> wrote:

> looks great!  thanks.
>
> just noticed that the highpass output is too hot.  instead of multiplying
> the distortion outputs by [1, -2, 1, 0, 0 ] , you need to multiply by [0.5,
> -1, 0.5, 0, 0], then you get the same amplitude for the highpass as the
> other modes.
>
> I'm gonna see what it sounds like to morph between filter modes with a
> line~ sweep.  Hopefully it will work somewhat.
>
> Matt
>
>
> On Sat, Feb 20, 2016 at 5:12 AM, Simon Iten <itensi...@gmail.com> wrote:
>
>> sounds great!!!
>>
>> thanks for sharing.
>>
>> > On 19 Feb 2016, at 20:06, cyrille henry <c...@chnry.net> wrote:
>> >
>> > 
>>
>>
>> ___
>> 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] one more filter

[i go bananas]

looks great!  thanks.

just noticed that the highpass output is too hot.  instead of multiplying
the distortion outputs by [1, -2, 1, 0, 0 ] , you need to multiply by [0.5,
-1, 0.5, 0, 0], then you get the same amplitude for the highpass as the
other modes.

I'm gonna see what it sounds like to morph between filter modes with a
line~ sweep.  Hopefully it will work somewhat.

Matt


On Sat, Feb 20, 2016 at 5:12 AM, Simon Iten  wrote:

> sounds great!!!
>
> thanks for sharing.
>
> > On 19 Feb 2016, at 20:06, cyrille henry  wrote:
> >
> > 
>
>
> ___
> 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] Does Pd have a "sound"?

[i go bananas]

Kinda weird onservation, but i seriously think pd would 'sound' different
if the standard UI came with a dark background and light objects.  As a few
people have pointed out, the interface does have a noticable influence on
the user.

Also, the default 64 sample blocksize, and the relatively expensive cpu
cost of upsampling or decreasing the blocksize do have noticable impact on
the fidelity.

The filters are also very rudimentary (although, the new bob~ one looks
more promising).  Of course it is possible to write your own with the
filter primitives, but it's hard work.

Something else:  being open source, means that the info and resources are
put together by the community with nobody really comitted full time to the
job of keeping it all together.  The big commercial alternatives all have
staff employed just to herd the users together and make sure their
resources get shared as well as possible.  Pd community is a bit stuck
together with paper clips in that regard.

But on the flip side, pd's community of users is probably the single most
awesome single group of people i have ever had the fortune of being a part
of.  Whenever you get stuck with something, there's always someone to lend
a hand, and whenever you help someone else, they generally are very
grateful.
And the limitations of not having a huge library of readymade techno tools,
is actually a real blessing.  In many ways, pd inspires out of the box
thinking.
In many ways it's easier to set up weird interactive interfaces and
algorithmic compositions than writing boring house music.  Personally i
would call that a plus.

Sorry, know this has gone pretty far off topic.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] error: maximum object loading depth 1000 reached

[i go bananas]

thanks Iohannes.  will use that in future.

i found my problem.  I'd left out a character in this bit:

frum_4osc_tilde_class = class_new(gensym("frum_osc~"),

(it should have been "frum_4osc~")
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] error: maximum object loading depth 1000 reached

[i go bananas]

hi,

i googled this error, and can see a bit of chatter about it, but not found
a solution yet.
My external was working fine, but i added a couple of things, and now when
i try to open it in pd, i get that error:

error: maximum object loading depth 1000 reached
anyone figure out the proper solution?  Have i done something wrong with my
external?

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

Re: [PD] configuring multiple readanysf~ objects for efficient playback

[i go bananas]

isn't readanysf~ just a more comprehensive version of readsf~ ?  ie. it
plays back files directly from the hard drive?

I'd think you'd be best advised to load your samples into tables and play
them back with [tabplay~] or [tabread4~] with that many at once.

On Sun, Feb 14, 2016 at 1:22 AM, Samuel Burt  wrote:

> Sorry, I forgot to include some of the console errors.
>
> (Tcl) INVALID COMMAND NAME: invalid command name "e,"
> while executing
> "e, audiofifo is 0.00 full."
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 $cmds_from_pd"(Tcl) INVALID COMMAND NAME: invalid command name
> "or"
> while executing
> "or getting frame...must be seeking"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 $cmds_from_pd"(Tcl) INVALID COMMAND NAME: invalid command name
> "rame...must"
> while executing
> "rame...must be seeking"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 $cmds_from_pd"(Tcl) INVALID COMMAND NAME: invalid command name
> "inet_high_1.wav"
> while executing
> "inet_high_1.wav"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 $cmds_from_pd"
>
> On Sat, Feb 13, 2016 at 11:16 AM Samuel Burt <
> composer.samuel.b...@gmail.com> wrote:
>
>> Dear list,
>>
>> I was tasked with building a sampler that reads back all the samples in a
>> directory, sequentially or randomly, with variable speed, polyphonic
>> playback. The subsequent object is then implemented multiple times.
>>
>> After a short amount of time, however, the GUI becomes unresponsive. I
>> can still manipulate the values of the GUI objects, but I won't see them
>> update. In addition, the Pd window Log 0 and above starts throwing (Tcl)
>> INVALID COMMAND NAME errors as you can see below. I'm guessing this is has
>> to do with not being able to read from the SSD quickly enough with around
>> 100 overlapping voices being loaded in a short amount of time? I'm not
>> really hearing any audio dropouts.
>>
>> I noticed that readanysf~ has some arguments. I'm hoping they might make
>> this process more efficient, but I don't understand them. Does anyone know
>> of any better documentation for readanysf~? The arguments are 1) number of
>> channels (mono, stereo, 3-chan, 4-chan, etc.), 2) number of "frames" in the
>> internal buffer --I don't understand how this effects the object--, and 3)
>> number of samples per frame in internal buffer --nor do I understand how
>> this might affect performance. I'm going to play around with these
>> arguments to see if it helps, but if anyone can weigh in with an
>> explanation, I'd appreciate it.
>>
>> Also, if anyone has a more efficient method for doing what I'm
>> attempting, please, let me know.
>>
>> Thank you,
>> Sam
>>
>>
>>
>>
> ___
> 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] how to share a .pd_darwin file?

[i go bananas]

thanks IOhannes,

verbose mode helped us realise that the file wasn't being found.

we found the culprit.  i had shared the file via facebook chat, and it had
clipped the tilde off the file name.

seems to be working now!

cheers
Matt

On Wed, Feb 10, 2016 at 7:57 PM, IOhannes m zmoelnig <zmoel...@iem.at>
wrote:

> On 2016-02-10 10:24, i go bananas wrote:
> > i just made my first proper external, and was so super chuffed that i got
> > it working.
> >
> > i'm on osx, so using .pd_darwin extension.
> >
> > i put it in my extra folder, made a demo patch in pd, and it works fine.
> >
> > only problem is, when i shared the .pd_darwin with 2 friends, it didn't
> > work for either of them. (i checked they had put it in the extra folder)
> >
> > does anyone have an idea what might be wrong?
>
> how about:
>
> tell them to Pd in verbose-mode ("-verbose"), and see whether the
> external can be found (and if it can't be found, this will give you a
> clue where Pd searches for the libraries).
>
> if it can be found, try to find out whether the dylib loader throws an
> error (e.g. on the stderr/stdout; so you might need to start Pd from the
> cmdline).
>
> do you use the same Pd version?
> Pd's API is very stable, but every now and then a new function is added.
> if you use such a new function in your code, then you cannot use the
> external with a version of Pd that predates the introduction of said
> function).
>
> do you (dynamically) link against non-standard libraries?
> are they present (and in a searched-for location) on your friends machine?
>
> fgmasdr
> IOhannes
>
>
> ___
> 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] How to index or loop through indices of a sound sample?

[i go bananas]

for just getting values, you can use tabread~, but for any pitch other than
the original, you'd be best advised to use the interpolated tabread4~



On Fri, Feb 5, 2016 at 9:55 AM, Matti Viljamaa  wrote:

> How can I index or loop through indices in a sound file like I’d do
> soundarray[i] trivially in most programming languages using arrays?
>
> -Matti
>
>
> ___
> 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] bunch of questions about switch~

[i go bananas]

Just want to confirm a couple of things.

If a parent patch has a switch~ object in it set to a certain blocksize,
and the subpatches have switch~ objects without creation arguments, will
those subpatches be set to the parent blocksize by default?

also, if the parent patch is switched off, will DSP also be switched off in
the subpatches?

i assume both answers are yes, but just want to make sure.

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

[PD] FM matrix with feedback

[i go bananas]

Hi all, hope everyone's well.

We're trying to implement a 4-op FM matrix with feedback, copying a patch
my friend made in reaktor using a block size of 1 (sorry, don't know the
full details of that, but he says he can get 1 sample delay for the
feedback)

Has anyone ever succeeded doing something like this in pd?  I know about
the order forcing using subpatches like in G.05.execution.order help patch,
but that doesn't seem like it will work here, as we still get DSP loop
errors when trying to connect the output of one osc~ back into the
frequency input of the others.

I'm really looking for a solution that doesn't involve using blocksize of
1, and anyway, even doing that, still seems the only way to do feedback
without getting DSP loop errors is with s~ / r~ pairs, which seem to only
work at blocksize of 64 anyway?

I don't mind adding a bit of latency to the whole system if there's maybe a
hack to do this with tables or something,,,but am really stuck here
wondering what to do.

any ideas?

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

Re: [PD] FM matrix with feedback

[i go bananas]

i just tried upsampling, but it seems to hit the cpu harder than lowering
blocksize, even.

and yeah, my friend just got a patch going using delwrite~ and vd~, which
we can use at blocksize of 1, and it works...  but the hit on the cpu is
harsh.

really looking for some way to do this at normal 64 sample blocksize at
normal samplerate

On Fri, Jan 8, 2016 at 7:03 PM, cyrille henry <c...@chnry.net> wrote:

> oh, I forget to say that you can also upsample the subpatch in order to
> reduce the feedback latency.
>
>
>
> Le 08/01/2016 10:54, cyrille henry a écrit :
>
>> s~ and r~ only work with 64 sample block, so you can't use them in this
>> situation.
>> but you can replace them using delwrite~ and delread~ with no delay, and
>> force order to write before you read.
>>
>> cheers
>> c
>>
>> Le 08/01/2016 10:42, i go bananas a écrit :
>>
>>> Hi all, hope everyone's well.
>>>
>>> We're trying to implement a 4-op FM matrix with feedback, copying a
>>> patch my friend made in reaktor using a block size of 1 (sorry, don't know
>>> the full details of that, but he says he can get 1 sample delay for the
>>> feedback)
>>>
>>> Has anyone ever succeeded doing something like this in pd?  I know about
>>> the order forcing using subpatches like in G.05.execution.order help patch,
>>> but that doesn't seem like it will work here, as we still get DSP loop
>>> errors when trying to connect the output of one osc~ back into the
>>> frequency input of the others.
>>>
>>> I'm really looking for a solution that doesn't involve using blocksize
>>> of 1, and anyway, even doing that, still seems the only way to do feedback
>>> without getting DSP loop errors is with s~ / r~ pairs, which seem to only
>>> work at blocksize of 64 anyway?
>>>
>>> I don't mind adding a bit of latency to the whole system if there's
>>> maybe a hack to do this with tables or something,,,but am really stuck here
>>> wondering what to do.
>>>
>>> any ideas?
>>>
>>> cheers, Matt
>>>
>>>
>>> ___
>>> 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] 0 length delay in delwrite~

[i go bananas]

You can use delwrite~ delread~ pairs to make feedback loops.  If a delay of
zero WAS actually permitted, these would form infinite loops.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Creation argument not working for pow~

[i go bananas]

yeah sorry, it's either a bug in OSX, some very obscure reason why it's not
working, or i am just actually dumb.

i right click 'get info' on a pd file, change the 'open with' application
to pd 0.46.7, and then click on "change all" to make all pd files open in
0.46.7.no error messages, all looks cool..

but now i just realised it is still opening pd files in the older 0.46.2

OSX10.10.3 and no i'm not updating it again, cos every time i update
OSX, i lose heaps of old stuff that i need cos mac doesn't care about
backwards compatibility.

i'm so grateful Miller does!

On Thu, Dec 10, 2015 at 6:20 PM, Alexandros Drymonitis <adr...@gmail.com>
wrote:

> Works for me too in Pd-0.46-7 on OS X 10.8.5
>
> On Thu, Dec 10, 2015 at 10:24 AM, IOhannes m zmoelnig <zmoel...@iem.at>
> wrote:
>
>> On 2015-12-10 05:20, i go bananas wrote:
>> > Just updated to newest pd vanilla.  The creation argument to pow~ seems
>> to
>>
>> not in my book.
>>
>> > $ git log d_math.c
>> > commit 5fd49d6be50391a6fd395a1cbb53d1dd65da45cb
>> > Author: Miller Puckette <m...@ucsd.edu>
>> > Date:   Wed Apr 29 12:18:43 2015 -0700
>> >
>> >fix pow~ to pay attention to its argument
>>
>> maybe your "newest pd vanilla" is not the newest after all?
>> (hint: it's often a good idea to specify the actual version number; e.g.
>> i'm running pd-0.46-7)
>>
>> gfmdft
>> IOhannes
>>
>>
>> ___
>> 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] Creation argument not working for pow~

[i go bananas]

Just updated to newest pd vanilla.  The creation argument to pow~ seems to
be ignored.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Efficient FIFO in Pd: How?

[i go bananas]

I was looking at the help patch for [pipe] the other day, and noticed that
there has been a change.  I think it was to allow symbols too.  (Sorry,
can't check on my phone now)


On Sunday, November 22, 2015, Roman Haefeli  wrote:

> Hi all
>
> I'm looking for a way to implement a FIFO buffer in Pd. I'd like it to
> be able enqueue messages with an arbitrary number of elements in order
> to retrieve them in the same order later. I came up with three different
> methods, but they are all either slow at enqueuing or at dequeuing or
> even both. It seems for a quick implementation you need something like a
> ring buffer, but I can't think of any method that would work for
> symbolic elements, too (as opposed to numbers).
>
> Attached patch comparison.pd compares the methods. Isn't there really a
> O(n) implementation as opposed to O(n^2)?
>
> Roman
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] pd needs something like soundcloud

[i go bananas]

there needs to be a simple place, that everyone knows, where you can upload
pd code to...EASILY

i mean, one click, and it's uploaded
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] libPd timing issue, seemingly caused by processing multiple 'ticks' of audio blocks.

[i go bananas]

We're trying to implement various sync options in an iOS libPd-based app,
and have run across a noticeable drift in the timing.  The app uses 8
'ticks' of 64 samples for faster devices, and 16 ticks for slower ones.
Basically what this means, is that messages are only being processed on
these larger multi-block boundaries of 512 or 1024 samples.  And that's not
good enough for keeping timing tight.

Of course, the first question is:  Has anyone already made a workaround to
this issue???

Or does anyone know of a way to make sure libPd processes messages with
proper timing, even with the 'ticks' value set quite high?

I have an idea for adding time delay messages to clock signals...so that
they can be sent through a [pipe] in pd to arrive at the correct time
during the block processing. But it looks quite tricky to implement, and
i'll wait to see if there is maybe a better solution first.

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

Re: [PD] libPd timing issue, seemingly caused by processing multiple 'ticks' of audio blocks.

[i go bananas]

Hi Chris, and thanks for your input.  Yeah this is for that Link stuff...

Thanks for the explanations and diagrams, and it's pretty much as i
guessed.

But i don't think you properly see what my workaround does.

See, the problem is not with latency, per say...because the Link framework
has that covered...so we can have quite a bit of latency, and as far as i
know, all devices just sync to the slowest one.

The problem is, that messages coming into libPd seem to only be processed
on these multi-block boundaries.  Even with just 10ms or 20ms of samples
per process loop, that's still a lot of drift for something like a drum
machine sending sync every 120ms or whatever.

So to go back to your diagram:

a: >XX|XX|X_|__|*_|__|__|__>

b: >XX|XX|XX|XX|*X|XX|X_|__>

in this case, i would assume that the * message sent to (a) is processed at
the beginning of the next multi-block.

BUT, i would also assume that the * message sent to (b) is also processed
at the beginning of the next multi-block - because:  messages are only
converted to audio on block boundaries. In this case, because you are
processing 8 blocks at once, then messages will only  be processed at the
beginning of the next 8 blocks, regardless of where they appear, or how far
the processing has proceeded.  I just can't see that it could be any
different.

So, what you get, is this system where messages are only processed in the
audio thread every time that multi-block boundary is reachedjust as
messages in pd itself are just added to the audio thread on block block
boundaries.

BUTthere is a workaround in pd.  You can use the scheduler, via
[delay], [pipe], [metro] to make sure that messages are triggered in the
audio thread between blocks.
It's that type of behaviour that i want to leverage to make sure that clock
messages are delayed the correct amount in the next block so that we don't
get this wonky sync.  Yes, i understand that means that we have to have
added latency, but as you said Chris,
"You can't really work around physics"

On Wed, Nov 11, 2015 at 11:42 AM, Chris McCormick <ch...@mccormick.cx>
wrote:

> Hello!
>
> On 11/11/15 09:18, i go bananas wrote:
>
>> We're trying to implement various sync options in an iOS libPd-based
>> app, and have run across a noticeable drift in the timing.
>>
>
> From Oliver's previous email I guess you're also trying to integrate
> Abelton's "link sync" with your libpd based apps.
>
> https://www.ableton.com/en/link/
>
> The app uses
>> 8 'ticks' of 64 samples for faster devices, and 16 ticks for slower ones.
>> Basically what this means, is that messages are only being processed on
>> these larger multi-block boundaries of 512 or 1024 samples.  And that's
>> not good enough for keeping timing tight.
>>
>> Of course, the first question is:  Has anyone already made a workaround
>> to this issue???
>>
>
> You can't really work around physics.
>
> Or does anyone know of a way to make sure libPd processes messages with
>> proper timing, even with the 'ticks' value set quite high?
>>
>> I have an idea for adding time delay messages to clock signals...so that
>> they can be sent through a [pipe] in pd to arrive at the correct time
>> during the block processing. But it looks quite tricky to implement, and
>> i'll wait to see if there is maybe a better solution first.
>>
>
> I don't think that will work.
>
> From your and Oliver's description (multiple blocks processed at once) you
> seem to be using libpd's PROCESS macro under the hood.
>
> https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L164
>
> Here is a diagram of what is happening (time goes from left to right).
> Hopefully I have this right:
>
> a: >XX|XX|X_|__|*_|__|__|__>
>
> b: >XX|XX|XX|XX|*X|XX|X_|__>
>
>  * The time between the greater than pipe symbols is the real time that
> each block boundary would occur.
>  * The time between the greater than signs is the real time that your
> 8-ticks of one block each would take.
>  * The X's are Pd crunching the numbers to produce output audio for all 8
> ticks in the next set.
>  * The asterisk symbol is a MIDI or other network based event that might
> come in.
>  * You don't hear the audio produced by the X's until the final greater
> than sign.
>
> As you can see in (a) sometimes the number crunching for the entire 8
> ticks is done well before the final greater than sign. Other times, as in
> (b) it only just completes just in time for the audio to come out of the
> speaker, which is presumably why you need to process 8 blocks at once. If a
> sync event arrives, what is libpd and Pd supposed to do? It has to wait
> until the next block of 8 ticks to process the event.
>
> What you 

Re: [PD] looking for other vanilla filters or abstractions for libPD

[i go bananas]

multimode mmb is wicked (as of course, is his whole library)

https://github.com/dotmmb/mmb

On Sat, Oct 24, 2015 at 8:02 PM, Joe White  wrote:

> Hey Scott,
>
> There's some good vanilla filters in rjlib -
> https://github.com/rjdj/rjlib/tree/master/rj - like [e_lop2], [e_lop4]
> and some biquad coefficient generators [u_bandpass1] etc...
>
> Cheers,
> Joe
>
>
>
> On 24 October 2015 at 09:45, Scott R. Looney  wrote:
>
>> hey folks, more of a libPD question than PD per se... i'm using libPD
>> with Unity for an upcoming iOS app i want to build and looking for good
>> synth filter alternatives. i may want to put it on the App store so using
>> anything with expr~ or fexpr~ is out, unfortunately. i recently ran into
>> the [bob~] object which seems useful and is under BSD license but initial
>> searches on how to compile externals in libPD have not been successful.
>>
>> ideally i'd love something i could just use in vanilla, as recompiling
>> libPD for C# is kind of a chore for my skillset. anyone got an idea where i
>> might find good vanilla resonant filters not using expr~/fexpr~ compatible
>> with libPD? or if anyone's got info on how to include externals in libPD
>> for Unity, i'm curious about that too. i'm currently using the uPD
>> framework from Magicolo, which is building on Patrick Sebastien's
>> LibPD4Unity concept, allowing multiple instances of PD to be run in the
>> game.
>>
>> anyway, any help appreciated!
>> scott
>>
>> ___
>> 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] prevent console error messages

[i go bananas]

as far as i know, there aren't any legitimate uses of vanilla objects that
generate error messages.  I have a pretty huge project, and the only thing
i get in the console is:

expr, expr~, fexpr~ version 0.4 under GNU Lesser General Public License

...and even that is just for a gui thing that doesn't go into the final
libpd release.

But when i used to use pd-extended and its objects, i often got unavoidable
warnings - stuff like " is not compatible with Windows" or
whatever...whether you would consider the warning a bug, or the
incompatibility a bug, is not something i can answer.

what errors are you getting Liam?  and with what objects?  there very well
could be a tidy way to avoid them.

On Tue, Oct 13, 2015 at 10:43 PM, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> wrote:

> What are some of those legitimate uses?
>
> A legitimate use of an object should not be generating
> an error in the first place.  So if that is the case it's a bug,
> and we should fix it.
>
> -Jonathan
>
>
>
> On Tuesday, October 13, 2015 9:13 AM, Liam Goodacre 
> wrote:
>
>
> Is there any way to prevent error messages from printing in the console? I
> know they're there for a reason, but there are some legitimate uses of
> certain objects that still generate error messages, and it would be nice to
> suppress them, at least while the patch is loading.
>
> ___
> 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] How does vline~ work under the hood?

[i go bananas]

Hi, me again.

Thanks for the discussion.  It has really opened my eyes.

So, i got my naive c++ implementation of line~ basically working.

And of course, just running a for loop incrementing by ticks, i run into
the exact precision error that this block quantizing seems to avoid.  My
line from 0 to 100 over 44100 samples only gets to 99.93

So, i also need to add something like pd's block quantization to make sure
my line goes all the way to the specified value.

My questions then are 2:

Is pd's method the way i should do it?  Or is there a better alternative?

And, if i do it the pd way, how does that work?  Does the increment get
updated every block?   Or is it just the last block that is stretched?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How does vline~ work under the hood?

[i go bananas]

yeah, am considering the option of just manually setting once the ramp
finishes.  But considering that i'm off by about 0.1% every 44100 samples,
it's a bit worrying.  Would be ok for synth envelopes, etc...but i'll
probably want to use this to lookup audio file tables, etc too, in the
future, so kinda want to get it spot on.

right now, the performDSP function is literally a single conditional and
then += increment, which seems nice and lightweight.  i'd like to aim to
keep it as close to that as possible...
/ rough clone of pd's line object:


using e_float = float;

class LineRamp
{
public:
	LineRamp();
	LineRamp(e_float target, e_float time);
	LineRamp(e_float initial, e_float target, e_float time);
	~LineRamp();
	
	void setLine(e_float target, e_float time);
	void setLine(e_float initial, e_float target, e_float timeMs);
	
	void trigger();
	
	void stop();
	
	void updateSampleRate(int newSampleRate);

	e_float performDSP();	
	
private:
	
	void commonConstructorStuff();
	
	void setTotalValueChange();
	void setMsPerSample();
	void setTotalTicks();
	void setIncrement();

void resetValues();
		
	unsigned long int sampleRate; // correct?
	
	bool initialise;
		
	e_float startValue;
	e_float targetValue;
	e_float currentValue;
	e_float totalValueChange;
	
	e_float increment;
	e_float msPerSample;
	e_float lineTimeInMs;
	
	unsigned long int totalTicks; // use longest int possible
	unsigned long int remainingTicks;
};


LineRamp::LineRamp()
{
	startValue = 0;
	targetValue = 0;
	lineTimeInMs = 0;
initialise = false;

	commonConstructorStuff();	
}

LineRamp::LineRamp(e_float lineTarget, e_float lineTime)
{
	startValue = 0;
	targetValue = lineTarget;
	lineTimeInMs = lineTime;
	initialise = false;
	
	commonConstructorStuff();	
}

LineRamp::LineRamp(e_float lineInitial, e_float lineTarget, e_float lineTime)
{
	startValue = lineInitial;
	targetValue = lineTarget;
	lineTimeInMs = lineTime;
	initialise = true;

	commonConstructorStuff();
}

LineRamp::~LineRamp()
{
//does nothing, OK?
}

void LineRamp::commonConstructorStuff()
{
	sampleRate = 44100;  // remove this magic number later!
setMsPerSample();

	currentValue = startValue;

resetValues();
}

void LineRamp::resetValues()
{
setTotalValueChange();
setTotalTicks();
setIncrement();
}


void LineRamp::setLine(e_float target, e_float timeMs)
{
	targetValue = target;	
	lineTimeInMs = timeMs;
	initialise = false;

resetValues();
}

void LineRamp::setLine (e_float start, e_float target, e_float timeMs)
{
	startValue = start;
	targetValue = target;		
	lineTimeInMs = timeMs;
	initialise = true;

resetValues();
}

void LineRamp::setTotalValueChange()
{
	totalValueChange = targetValue - currentValue;
}

void LineRamp::setMsPerSample()
{
	msPerSample = sampleRate * 0.001;
}

void LineRamp::setTotalTicks()
{
	totalTicks = msPerSample * lineTimeInMs;
}

void LineRamp::setIncrement()
{
	if (lineTimeInMs == 0)
	{
increment = totalValueChange;
	}
	else
{
increment = totalValueChange / totalTicks;
}
}

void LineRamp::updateSampleRate(int newSampleRate)
{
	sampleRate = newSampleRate;
	setMsPerSample();
	setTotalTicks(); 
	setIncrement(); 
}

void LineRamp::trigger()
{
	remainingTicks = totalTicks;
	
	if (initialise)
	{
		currentValue = startValue;
resetValues();
	}

}

void LineRamp::stop()
{
	remainingTicks = 0;
}


e_float LineRamp::performDSP()
{
	e_float output = currentValue;
	
	if (remainingTicks)
	{
		currentValue += increment;
		--remainingTicks;
	}
	return output;
}

/*

notes:  

!! currently, there is the possibility of a race condition if trigger() is called during the performDSP loop?

!! still not checking if line actually makes it 100% of the way to its target.  This may be ok for all intents and purposes?

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

Re: [PD] How does vline~ work under the hood?

[i go bananas]

Audibility of zipper noise would depend on the ramp length (shorter ramp
would have bigger zip jumps) , but would also depend heavily on what is
being done with the ramp.  Ramping the volume of a long bass tone would be
much more audible than ramping the volume of a noisy wind sample.

Matt, yep, should have been doing my processing with doubles too.  That's
really made it better.

For any purpose i will use, incrementing by double, and then setting the
final tick to target value looks like it will be more than good enough.

Actually, guess i'll probably just throw in a second performDSP method,
without using the conditional to set that final tick.  For audio envelopes,
i don't care too much if it only goes to 0.9993 instead of 1
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How does vline~ work under the hood?

[i go bananas]

My apologies for doubting you Jonathan.  The line object does indeed
stretch to fill the whole block.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] How does vline~ work under the hood?

[i go bananas]

Thanks,

I guess here is my question put better:

If i make a line and a vline object, and feed them both a [1, 0 50(
 message, they perform differently.  The line object jumps around,
presumably cos it is tied to block boundaries.
But the vline always triggers exactly the same.

It's as if somehow the vline~ works outside of the block structure.  Does
it actually do that?  Say you're at sample 47 of a 64 sample block, does
vline jump the queue and trigger right then?

Or i guess, even more succinctly, i was assuming that everything in pd got
triggered in blocks.  Is that the case?  Does vline also have to wait for a
block boundary when first triggered?

Sorry, there's obviously some 'aha' moment i'm failing to have here.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How does vline~ work under the hood?

[i go bananas]

In that case, maybe an even simpler question:

What is the difference between sending a [1, 0 50(  message to vline as
opposed to line ?

Why does line exhibit jitter, if both only trigger on block boundaries?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] How does vline~ work under the hood?

[i go bananas]

I actually think Frank might have the my answer here.

What i'm noticing, is not an inconsistency in the length of the ramps.
It's an inconsisency in when they are first triggered.  This is for stuff
like the initial click of a bassdrum, so you can even hear the difference
quite clearly.  The line object jumps around, as it is being triggered on
block boundaries, but the vline object is faithfully consistent in starting
at the exact TIME i ask it to - regardless of blocksize, etc.

The only logical answer i can see here, is the one Frank has given.  I'm
scheduling drums using a clock controlled by metro.

So what i'm guessing that Frank is suggesting here, is that the scheduler
is keeping a list of all the metro and delay bangs that should arrive in
the upcoming block, and sceduling them to be hit while the block plays.
And what vline does, is it reads that list, and then schedules itself to be
hit after the correct amount of logical time has elapsed.

And i would guess that the normal line object is not capable of that.  It
just waits until block boundaries and starts its simple incrementation.

So, going back to Jonathan's day-long block example, i can see now how that
works.  the line can only be triggered once, at the start of the block (i
still have doubts that it would actually stretch to the length of the block
though.  I reckon a 50ms line is still gonna take 50ms. )
But the vline has that linked list inbuilt, and it reads from the scheduler
to see when it should be triggered.  So if you had the day-long block, then
vline's linked list is gonna end up with a full day's worth of messages in
it!

Anyway, i'll go back to the source code tomorrow and have another look.
But pretty sure that i now see how it is the ability to look ahead at metro
scheduled events that gives vline the accuracy i need.

Thanks Matt for suggesting i look at the clock, and scheduler code, thanks
Jonothan for the great example of the day long block - taking things to
extremes like that is a good way to see how they work.  And thanks Frank
for finally turning on that lightbulb and suggesting the role that metro
was playing here.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] How does vline~ work under the hood?

[i go bananas]

I want to recreate the timing accuracy of vline~ in a c++ project, and
there's something that i can't figure out exactly - how does it act,
seemingly outside of the block construct, to get its accuracy?

in the source code, there is a calculation for elapsed logical time, and i
assume that has something to do with it?

if i make a vline~ from 0 to 1, over 10ms, does this mean that it actually
doesn't START right on 0, but rather starts at a slightly offset value to
compensate for the block boundary?

any help would be appreciated!
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

[i go bananas]

not talking about connection order, but rather creation order.  If you cut
an object, and then paste it, it will jump to the front of the object
queue.

Say you created a [delwrite~] / [delread~] pair, in that order; if you cut
the [delwrite~] and then pasted it back, then it would come after the
[delread~] and your patch's behaviour would change.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Documentation of the various GUI objects and what their creation parameters represent.

[i go bananas]

Thanks!  That does it nicely :)

On Tue, Sep 1, 2015 at 9:49 AM, Jonathan Wilkes <jancs...@yahoo.com> wrote:

> I identified each argument for every iemgui.  You can find it in the help
> patches for Pd Extended.
>
>
>
>
> On Monday, August 31, 2015 7:55 PM, i go bananas <hard@gmail.com>
> wrote:
>
>
> Hi List,
>
> to save me the time of doing what several people have already done before,
> is there a list of all the GUI objects and what each of their creation
> parameters represent?
>
> for example, when i make a simple toggle near the top left hand corner of
> my patch, it will be listed as:
>
> #X obj 7 7 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1;
>
> Of course it's pretty obvious what each part represents, but perhaps
> somebody has complied a list of all these objects, so i don't have to do it
> again?
>
> cheers, Matt
>
> ___
> 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] Documentation of the various GUI objects and what their creation parameters represent.

[i go bananas]

Hi List,

to save me the time of doing what several people have already done before,
is there a list of all the GUI objects and what each of their creation
parameters represent?

for example, when i make a simple toggle near the top left hand corner of
my patch, it will be listed as:

#X obj 7 7 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1;

Of course it's pretty obvious what each part represents, but perhaps
somebody has complied a list of all these objects, so i don't have to do it
again?

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

Re: [PD] G05.execution.order issue (bug? just wrong?)

[i go bananas]

the delwrite~ must come first (which is exactly what happens when you force
the order by putting the delread~ into a subpatch.

i would also guess that send~ must come before recieve~, etc etc.  In all
cases , you have to write before you can read.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] G05.execution.order issue (bug? just wrong?)

[i go bananas]

Yes, you can get 'correct' execution order by just adding your objects in
the right order.  But it is unclear from looking at the patch.  Also, if
you perform a cut and paste or rename your objects, you risk changing the
order.

Thus it is always safest to use the subpatch, as it will force the order,
regardless.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [cos~]replacement for webPd patch

[i go bananas]

Cos~ is vanilla pd.  How does it not work?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] A patch to create a patch to create a patch to create a patch to close puredata...

[i go bananas]

these are awesome.

On Fri, Jul 17, 2015 at 8:23 PM, Benjamin ~ b01 ben...@free.fr wrote:

 nice piece of digital art ;)

 btw, does someone on the list have an old patch that was producing a
 nice gui animation inside Pd ?
 I saw it a long ago @ Pd Conv Montreal ...

 thanks
 ++
 benjamin

 Le 15/07/2015 01:30, Olivier Baudu a écrit :
  Sorry list...
 
  I can't refrain myself... :-p
 
  The Bangarland :
  https://vimeo.com/133499700
 
  Cheers...
 
  01
 
  Le 06/07/2015 22:04, Jaime E Oliver a écrit :
  nice indeed!
  J
  On Jul 6, 2015, at 2:10 PM, Jack j...@rybn.org wrote:
 
  Hello Olivier,
 
  Very nice ;)
  ++
 
  Jack
 
 
 
 
  Le 06/07/2015 20:46, Olivier Baudu a écrit :
  Thank you Julian...
 
  Well, I don't know if this one is funny but, for sure, it's still
  useless... :-)
 
  The Carouslide: https://vimeo.com/132739686
 
  :-p
 
  01
 
  Le 01/07/2015 15:02, Julian Brooks a écrit :
  definitely raised a smile :)
 
  2015-06-30 17:15 GMT+01:00 Olivier Baudu 01iv...@labomedia.net
  mailto:01iv...@labomedia.net:
 
  Hi list...
 
  I got bored again... so...
 
  https://vimeo.com/132195870
 
  :-p
 
  Cheers...
 
  °1
 
  Le 24/06/2015 17:34, Olivier Baudu a écrit :
  Hi list...
 
  I had time to waste so here you are :
 
  https://vimeo.com/131648084
 
  :-p
 
  Cheers...
 
  °1ivier
 
 
 
  ___
  Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing
  list UNSUBSCRIBE and account-management -
  http://lists.puredata.info/listinfo/pd-list
 
  -- On ne peut pas vivre dans un monde où l'on croit que
  l'élégance exquise du plumage de la pintade est inutile. Ceci est
  tout à fait à part. J'ai eu envie de le dire, je l'ai dit. Jean
  Giono, Un roi sans divertissement.
 
  ___
  Pd-list@lists.iem.at mailto: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


 ___
 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] questions about [send]/[receive]

[i go bananas]

when 2 different [send A]'s go to the same [receive A] will there be used
a first-in first-out procedure?

yes, always.

(unless you deliberately use something such as a [pipe] or [delay] object
in between, of course)


[send]/[receive]'s inside a subpatch are they handled before
[send]/[receive]'s which 'cross the border' of the subpatch?

no.  the subpatch will not have any impact on the order of execution.



In general, it is bad practice to use a single send going to multiple
receives - the order in which they are received should be considered
undefined.  You should avoid doing that if at all possible.

But in some cases, it is useful, such as sending the global BPM to
different parts of your patch. In that case, you just have to be very
careful that the patch doesn't depend on the order in which the different
receives are triggered.

On Tue, Jul 14, 2015 at 6:07 AM, Peter P. peterpar...@fastmail.com wrote:

 * ro...@dds.nl ro...@dds.nl [2015-07-13 16:40]:
 
  hi list,
 
  to not make a maze of a complicated patch
  i use quite often send/receive objects inside the patch.
 
  triggered by the recent thread about execution order and depth-first,
  i'm starting to doubt the above mentioned habit.
 
  in an much older thread it is said that:
   apart from the right to left rule for outlets (and inlets?)
  and the depth first rule,
  execution order in Pd is not defined.
 
  does it mean that there's nothing to say/know about send/receive's?

 http://puredata.info/docs/tutorials/PdForMaxUsers#always-use-the-trigger-object

 ___
 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] [initbang] vs [loadbang]

[i go bananas]

oops.  yeah, i monged it up.

Had forgotten to delete the dynamically created inlets from my test patch.
 :p
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [initbang] vs [loadbang]

[i go bananas]

That is an awesome hack!  Nice one IOhannes :D

Just did a simple test, and it seems you can just take the basic idea and
wrap that up as an abstraction to use as a replacement for [initbang],
wherever you need it.

Also, i tried using \$0, to avoid the need for the spigot.  PD console
prints an error:  $0_initbang: no such object, but the bang does actually
seem to be sent.







On Mon, Jul 6, 2015 at 5:51 AM, Jack j...@rybn.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Without this last line in the abstraction, it is possible to use
 something like :
 $ sed -i '/inlet;/d' ./dynin.pd  if [[ $(tail -n1 dynin.pd) !=
 _initbang bang; ]] ; then echo _initbang bang;  dynin.pd ; fi 
 pd dynin-test.pd
 Then you can save your abstraction, this is ugly but seems to work...
 ++

 Jack



 Le 05/07/2015 22:07, Jack a écrit :
  Yes, nice, all is in the last line in the abstraction ;) ++
 
  Jack
 
 
 
  Le 05/07/2015 22:01, Roman Haefeli a écrit :
  On Son, 2015-07-05 at 21:04 +0200, IOhannes m zmölnig wrote:
  On 07/05/2015 08:57 PM, Alexandros Drymonitis wrote:
  saving the dynin.pd abstraction, will break it.
  [...]
  abstraction. I put [r _initbang] but it won't work.
 
  the trick is *not* to have a [r _initbang] in your patch. the
  trick is to generate a message sent to the _initbang label.
  this is a fragile hack, hence all my warnings; esp. the first
  warning do not save is for real - and it's not because you
  will save the dynamically generated objects, but because it
  will break the init logic.
 
 
  and i would very much prefer if anybody who wants to use that
  trick discovers themselves how it actually works (e.g. by
  studying the patch i gave).
 
  Despite your slight tone of discouragement to use such a hack,
  it's still a cool and smart hack. Thanks for sharing.
 
  Roman
 
 
  ___
  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
 

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJVmZjeAAoJEOuluecjw8GUCsMH/jpLsZiBW21Io1sYI4f/PQYi
 ltCZmSvJk9/qQ1xRkEPU0TT8TTEKl62otRplT8h91J4tIR/4Z1Uuvx7601o+NpCK
 udRyoK3E0adleK5xcF+NjMSJTjcR7C+DItQqtIY6YQyKFESgumhjfxwQsMtMVr/d
 w9pAmE96bzHT6oZR/8eqhVF0ktlnY+4iw9NE8x+4eIi5JycWoFiXBy8A+pHKyfSU
 IdnR06WlqguW2cnHyUbYzr2JiL1dRmrWYMqkbWcPf9XBVmsuvm1EpE7/MvBWcnX6
 Pr1qjA5uEPqY737QiGhhw0RPokhZPHXkpSlg/GYmf2E4+nCmg78FWW02C6V7RhU=
 =o5pJ
 -END PGP SIGNATURE-

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



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

Re: [PD] Vanilla replacement for tanh~

[i go bananas]

there's a good approximation for tanh that can be made using just a couple
of simple arithmetic objects:

formula is:  tanh(x) ~= x*(27+x*x) / (27+9*x*x)

it's close enough for every application i've ever come across, it's cheap
cos it only uses simple arithmetic, and it doesn't degrade the resolution
of your signal like a table lookup does.



On Fri, Jul 3, 2015 at 12:56 PM, Chris McCormick ch...@mccormick.cx wrote:

 On 03/07/15 03:06, Pagano, Patrick wrote:
  Is there a way i can replace something for tanh~
  and inits in Vanilla 46?

 Using a pre-computed table for speed:

 https://github.com/chr15m/blockhead/blob/master/e_tanh.pd
 https://github.com/chr15m/blockhead/blob/master/e_tanh-help.pd

 Or install blockhead using deken. :)

 Cheers,

 Chris.

 --
 http://mccormick.cx/

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



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

Re: [PD] weird bug, patch doesn't seem to work for no reason

[i go bananas]

it works at low frequencies.

i think at higher freqs, you'll start getting errors because the slave
phasor's phase is only reset on block boundaries, so you have the potential
for 63 samples of deviation.

this is why converting from the signal to message domain and back again is
never usually a good idea if you need accuracy.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Granular Synthesis on liv input?

[i go bananas]

i made one years ago.  i remember it being quite a cpu hog, but it sounded
ok.

http://forum.pdpatchrepo.info/topic/1824/grannie-basher-delay-line-granulator

On Mon, May 18, 2015 at 5:02 AM, Lorenzo Sutton lorenzofsut...@gmail.com
wrote:

 On 17/05/15 18:20, Pagano, Patrick wrote:

 Hi i am trying to build a granular instrument for a prototype Pd
 eurorack module

 I am using Pd-Vanilla and Raspberry Pi and Arduino


 is there a patch out there that does granualr on live input i can use
 for testing the setup?


 Granita [1] includes a basic but functional 'live looper' and is vanilla
 friendly. The live input can be seen in a demo video (at around 10:20) [2]

 It is however a bit CPU hungry, but includes lighter versions (see
 Granita64.pd and Granita32.pd): it would be actually be interesting to see
 if/how it works on R-Pi... In case you try it let me know :-)

 Lorenzo.


 [1] https://puredata.info/downloads/granita-minimalist-granular-synthesis
 [2] https://vimeo.com/36609964


 ___
 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] zexy/wrap for audio

[i go bananas]

this seems to work

On Sat, May 16, 2015 at 10:07 PM, Alexandre Torres Porres por...@gmail.com
wrote:

 hey, there is one object that does it after all, and it's a max clone from
 cyclone. Meet: [pong~], it wraps and also folds (which was something else I
 wanted as well, haha).

 cheers

 2015-05-16 9:49 GMT-03:00 Alexandre Torres Porres por...@gmail.com:

 Hi, this doesn't seem to be working actually, I tried the range 2-5 and it
 didn't happen. But I've already made me a workaround with [expr~] anyway,
 and I also tried another option similar to this for the range of -1 and 1.
 I bet there is a simple workaround this way too to make it generic to any
 range, but I wouldn't say it is trivial and simple, it can make the
 quest for an object like this sound silly or banal, but I still think (even
 by having found a workaround mysef) that it'd be just really simpler if
 there was an object for it. So I'd like to make the suggestion for one. It
 could be an abstraction like this.

 thanks

 thanks.

 2015-05-16 3:20 GMT-03:00 Cyrille Henry c...@chnry.net:



 Le 16/05/2015 00:24, Alexandre Torres Porres a écrit :

 phasewrap~ wraps a signal between -pi and pi
 wrap~ wraps between 0 and 1

 so none of them behaves like zexy/wrap, which can wrap between any
 given range.

 diference is only very simple math.

 see attachment.

 cheers
 c


 cheers

 2015-05-15 18:31 GMT-03:00 Cyrille Henry c...@chnry.net mailto:
 c...@chnry.net:

 wrap~ from vanilla
 cheers
 c


 Le 15/05/2015 22:37, Alexandre Torres Porres a écrit :

 howdy, looking for a zexy/wrap like object that works for
 audio, hints?
 thanks


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


 ___
 Pd-list@lists.iem.at mailto: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




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

Re: [PD] libpd for ios video tutorial

[i go bananas]

yeah we called it LIBB Pee Dee
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] examples of classic Sample and Hold

[i go bananas]

you can create other waveforms in the control domain too ;)

(positive saw wave)

[metro 10]
|
[f ]x[+1]x[mod 100]
|
[/ 100]

(sine)

[metro 10]
|
[f ]x[+1]x[mod 100]
|
[/ 100]
|
[cos]

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

Re: [PD] examples of classic Sample and Hold

[i go bananas]

for sample-and-hold, as it is usually implemented for pitch in a synth, you
actually don't even NEED to use the samphold~ object!  you can just use a
metro to simulate the clock, and then a random to simulate the noise input
(that's what was usually used for synth sample and hold madness).


[metro 125]
|
[random 5000]
|
[/ 100]
|
[+ 40]
|
[mtof]
|
[phasor~]
|
[*~ 2]
|
[-~ 1]

likewise, you can use the same process for sample and hold on a filter by
just adding a short [line~ 10] after the [mtof] and feeding that into the
2nd inlet of [vcf~]

or of course, you could run one process on the pitch and another on the
filter, but just make sure to use a slightly different random number base
to make them independent,



On Thu, Apr 16, 2015 at 10:37 AM, William Huston williamahus...@gmail.com
wrote:

 As I understand it, a classic sample and hold
 is capturing the instantaneous input voltage
 of an incoming signal, and remembering it.

 [metro 5]
 [adc~]
 |/
 [snapshot~]
 |
 [f]

 The [metro 5] is also banging on the [snapshot~]'s hot inlet
 with [adc~] if want samples at 5ms intervals.

 However, these days, in my own mind at least,
 I think about sample and hold as meaning,
 read a few seconds of audio from a source
 into a memory, and loop it.  I don't know if others
 think this way also.

 That would be a more complex circuit.

 BH





 On Wed, Apr 15, 2015 at 6:36 PM, Pagano, Patrick 
 p...@digitalworlds.ufl.edu wrote:

  Hello Everyone


  I am wondering if people would be willing if they have an example of
 Sample and Hold to use for a project i am working on.

 I am interested in the classic sounding Sample and Hold insanity please
 share a patch if you have one so i may learn on how to make one properly

 the one in the help files is not the kind i am talking about


  i hope this makes sense


  pp


   *Patrick Pagano B.S, M.F.A*
 Audio and Projection Design Faculty
 Digital Worlds Institute
 University of Florida, USA
 (352)294-2020

 ___
 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)

 Don't forget to sign the

 *Pledge to Resist*

 *the Constitution Pipeline:*

- *The Pledge: TinyURL.com/Pledge2ResistCP
http://TinyURL.com/Pledge2ResistCP*
- *More info: TinyURL.com/Pledge2ResistCP1
http://TinyURL.com/Pledge2ResistCP1*


 ___
 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] bandlimited wavetables for pd vanilla

[i go bananas]

awesome, thanks claude.

On Fri, Feb 13, 2015 at 1:06 AM, Claude Heiland-Allen cla...@mathr.co.uk
wrote:

 Hi all,

 Today I implemented bandlimited wavetables in Pd vanilla using the idea
 behind mipmapping in OpenGL (ie, generate many filtered and downsampled
 versions of a source, use the most appropriate version(s) by a function of
 the derivative of the lookup index).

 More info and full source (quick start tutorial: bl-example.pd):

 https://gitorious.org/maximus/pd-bl

 License: same as Pd vanilla.

 Advantages over other implementations:
 * Can generate wavetables from any waveform stored in a table.

 Disadvantages:
 * The higher harmonics are reduced compared to an optimal method.


 Claude
 --
 http://mathr.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] [env~] issues

[i go bananas]

I'm surprised about this double bang, but I suppose this means do
compute one audio block and only one (here 1024 samples).

actually, i have NO idea why i needed to do the double bang.  For some
weird reason, a single bang was triggering the [switch~], but then the next
bang did nothing.  Only every second bang was triggering.  So, i used [t b
b] just to send 2 bangs and trigger every time.

if you remove one cable from one outlet of the [t b b], you will see what i
mean.

not sure if there's a bug in the implementation, or what, but yeah...seems
weird.


I wonder if switching the DSP off does mess up with overlapping (as i
understand overlapping with previous audio block).

 sorry, i don't actually know how the overlap is implemented, but I did
some trial and error tests, sending various signals through the switched
off subpatch, and through a subpatch with no [switch~] object.   The
outputs of each [env~] in the different subpatches seems to be the same.





On Fri, Dec 19, 2014 at 12:37 PM, Billy Stiltner billy.stilt...@gmail.com
wrote:

 you can never really get the real response of a room because the
 temperature an air currents are always changeing., you can however get a
 very close approximation maybe.



 ___
 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] Artikulation - datastructures

[i go bananas]

and how many years work would it take to do that in pd data structures?

On Thu, Dec 4, 2014 at 5:04 PM, Chris McCormick ch...@mccormick.cx wrote:

 https://www.youtube.com/watch?v=71hNl_skTZQ
 --
 http://mccormick.cx/

 ___
 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] klank in pd?

[i go bananas]

what does it do?


On Wed, Nov 12, 2014 at 12:12 PM, Alexandre Torres Porres por...@gmail.com
wrote:

 Hi, in SC there's such a thing called Klank, do you know it?

 wonder if there's such a thing in Pd as well, or how to do it.

 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] Yellotron : a mellotron in Pd

[i go bananas]

that's awesome.  Nice one Pierre. :D

On Tue, Nov 11, 2014 at 11:08 PM, Pierre Massat pimas...@gmail.com wrote:

 Dear list,

 I wanted to shared with you a simple implementation of the mellotron in
 Pure Data, which I made using free mellontron samples I found online.
 Everything is explained and available for download in a blog post I just
 published :
 http://guitarextended.wordpress.com/2014/11/11/yellotron-a-mellotron-with-pure-data/

 And as a bonus here's a song I made using the yellotron (cello and choir)
 : https://pi-r.bandcamp.com/track/sur-les-deux-h-misph-res

 Cheers,

 Pierre.

 ___
 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] Should message objects be able to pre-parse $0 into valid dollarzero?

[i go bananas]

what about using a new symbol altogether for message boxes to pass creation
arguments and $0 value?

maybe @0. @1, etc???
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list