On Thu, Aug 9, 2012 at 3:03 PM, Alexandre Torres Porres
wrote:
> Awesome, in fact I'm particularly interested in doing pitch shift on the fly
> as well, how do you do that?
>
> And what about these limitations of [tabread4~]? I'm getting the idea it's
> all a matter of better quality in the record
Awesome, in fact I'm particularly interested in doing pitch shift on the
fly as well, how do you do that?
And what about these limitations of [tabread4~]? I'm getting the idea it's
all a matter of better quality in the recording of the audio, is it right
or is there any other feature?
And moreove
Hi Alex,
I suppose the 'bigger picture' is that we have accomplished the 1st step in
attempting to plug a perceived lack in current Pd which is a [tabwrite4~]
object. [ipoke~] for MaxMSP came up a few times on the list recently and
someone mentioned 'could we get the source off him?' So I asked
t.
cheers
alex
--
>
> Message: 1
> Date: Thu, 9 Aug 2012 11:20:49 +0100
> From: Julian Brooks
> Subject: Re: [PD] ipoke~_v.3_test1 for Pd
> To: Pierre Massat
> Cc: PD List
> Message-ID:
> <
> cagembftg3vk6ez69ntrigvkduuzhqqxpce21hnxekgt+jyx...@mai
Hi Pierre,
Well I would say check the test patches first off and come back if you
require more info...
Katja's description on the forum is here:
http://puredata.hurleur.com/viewtopic.php?pid=32209#p32209
Cheers,
Julian
___
Pd-list@iem.at mailing list
*
>
> This is an early beta release so please test and share your experience.
>
>
> Special thanks to P.A. Tremblay for making this happen.
>
>
> Pd ipoke~ is released under a 3-clause BSD license.
>
> Pd port by Katja V
_v.3_test1.zip
*
This is an early beta release so please test and share your experience.
Special thanks to P.A. Tremblay for making this happen.
Pd ipoke~ is released under a 3-clause BSD license.
Pd port by Katja Vetter Aug
Thanks for your mediation Julian. Pierre Alexandre sent ipoke~.c to
Charles and to me. If anyone else interested in collaboration on a Pd
port please join in. P.A. plans to release ipoke~ under BSD-ish
license. Hopefully he'll do that soon so we can discuss details on
list, share test versions etc.
Hey all,
Spoke to P.A. who has asked for any interested party to contact him
directly for the source code.
p.a.tremb...@hud.ac.uk
Cheers,
Julian
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo
e one object
> which could do both and, as of yet, other unforeseen things.
>
> Perhaps too a reasonably straight port of [iPoke]? would be a good first
> project to get this moving towards the proposed [tabwrite4~] or is part of
> the problem that currently within Pd [iPoke~] is just
nforeseen things.
Perhaps too a reasonably straight port of [iPoke]? would be a good first
project to get this moving towards the proposed [tabwrite4~] or is part of
the problem that currently within Pd [iPoke~] is just not doable?
BTW, my 2-penneth, etc etc - naming wise, if we have hit upon someth
Hi Joseph,
I'm back and rereading the thread to attempt to get a grip on this.
Just wanted to say that I hope you don't mind that your initial post has
exploded into something else - you triggered a good one though, well done.
I would be delighted to have a peek at your solution to this (admitte
On Thu, Jun 21, 2012 at 9:28 AM, Matt Barber wrote:
> I'm not sure how [ipoke~]
> does what it does, but I'd want to leave the idea of several
> approaches open (maybe along the lines outlined in this thread) to see
> what will work best for Pd.
>
> Matt
One thing to consider is the possibility o
Hey Matt,
Excellent news. A flexible approach sounds right too. You know, as a
non-Max'er I actually have never seen iPoke~ in action! I know more about
it through this thread than anything else.
Anyways, good stuff.
Regards,
J.
___
Pd-list@iem.at
Yep, count me in. I'm going to be out for a week but will have email
access on my phone.
A couple of years ago there was a big discussion about different cubic
interpolators, and some of us put together classes and did some
benchmarking on the different approaches. I'm not sure how [ipoke~]
does w
om
To: katjavet...@gmail.com
CC: pd-list@iem.at
Subject: Re: [PD] ipoke~ ?
Apologies for the delay in responding, I'm also away atm.
Katja & Matt (and anyone else) - we should contact P.A. and get this moving.
It may be best if we formulate an email between us to get the source c
Apologies for the delay in responding, I'm also away atm.
Katja & Matt (and anyone else) - we should contact P.A. and get this
moving. It may be best if we formulate an email between us to get the
source code, rather than us all contacting him separately, and take it from
there. I'm more than ha
- Original Message -
> From: Matt Barber
> To: Jonathan Wilkes
> Cc: katja ; pd-list
> Sent: Sunday, June 17, 2012 10:48 AM
> Subject: Re: [PD] ipoke~ ?
>
> On Sun, Jun 17, 2012 at 3:16 AM, Jonathan Wilkes
> wrote:
>> What does Csound&#
On Sun, Jun 17, 2012 at 1:34 AM, Simon Wise wrote:
> On 17/06/12 12:37, Matt Barber wrote:
As far as mixing vs. overwriting is concerned, that actually depends
on what it's trying to model. Overwriting is probably right for a
looper, but mixing is right for a recording of a mov
On Sun, Jun 17, 2012 at 3:16 AM, Jonathan Wilkes wrote:
> What does Csound's vdelayxw do: mix or overwrite?
>
It's based on "approach A" -- mixing a kernel into the buffer, so it
mixes automatically. The read head of the delay line zeroes each
sample out after reading.
Matt
What does Csound's vdelayxw do: mix or overwrite?
-Jonathan
- Original Message -
> From: Matt Barber
> To: katja
> Cc: pd-list
> Sent: Sunday, June 17, 2012 12:37 AM
> Subject: Re: [PD] ipoke~ ?
>
>>> As far as mixing vs. overwriting is concerne
On 17/06/12 12:37, Matt Barber wrote:
As far as mixing vs. overwriting is concerned, that actually depends
on what it's trying to model. Overwriting is probably right for a
looper, but mixing is right for a recording of a moving sound source -
and because [poke~] doesn't interpolate it's not an i
>> As far as mixing vs. overwriting is concerned, that actually depends
>> on what it's trying to model. Overwriting is probably right for a
>> looper, but mixing is right for a recording of a moving sound source -
>> and because [poke~] doesn't interpolate it's not an issue (it wouldn't
>> be usef
On Sat, Jun 16, 2012 at 7:16 PM, Matt Barber wrote:
>> When the index goes backwards in the table, the object should write
>> backwards, like [poke~] does. In my view, the object should always
>> overwrite samples, like [poke~] again. I did my sound-on-sound looper
>> with [poke~] and [tabread4~]
On Sat, Jun 16, 2012 at 12:03 PM, katja wrote:
> On Sat, Jun 16, 2012 at 5:01 PM, Matt Barber wrote:
>
>> The user-settable bound would just be in how they decided to use it.
>> Think of it like [until] -- there's no reason to make the user set an
>> upper iteration bound - the user does that jus
On Sat, Jun 16, 2012 at 5:01 PM, Matt Barber wrote:
> The user-settable bound would just be in how they decided to use it.
> Think of it like [until] -- there's no reason to make the user set an
> upper iteration bound - the user does that just by using it in a way
> that doesn't crash Pd (and so
On Fri, Jun 15, 2012 at 3:34 AM, Matt Barber wrote:
> If it used the same interpolator as tabread4~, you could in principle
> do approach B -- you'd need a struct that held on the the last samples
> of the previous block, and offset it by a sample.
>
> So, let's say you have a blocksize of 4, the
On Fri, Jun 15, 2012 at 11:37 AM, Julian Brooks wrote:
> If iPoke~ is of use to our community then I think we
> should give it a crack. P.A. has very decent coding skills, is supportive
> of our aims (though has yet to be convinced of its real-world application
> apart from Pd vanilla) and this
Hey Matt,
Thanks for chiming in on this...
I must admit that most of the above is operating way above my understanding
but I'm learning (which I like). Not sure what I could do apart from being
an initial conduit and making myself available for some stress-testing,
assist with help-file etc. if
On Thu, Jun 14, 2012 at 9:23 AM, Julian Brooks wrote:
> Been in touch with P.A. (he's my supervisor at Huddersfield) and he would be
> delighted to have a Pd version of iPoke~. If we get a posse together, or if
> someone is happy to take it on, he's more than happy to share the source
> code with
> But... today I realized why approach B could not work at all for an
> object which takes float indexes as arguments for writing, like you
> would expect from [tabwrite4~], [ipoke~] or any variable speed writer:
> for each perform loop, you get N (=blocksize) signal values and
> equally many index
On Thu, Jun 14, 2012 at 8:41 PM, Miller Puckette wrote:
> I've been thinking about this for some days. I agree there are two
> fundamentally different approaches (A: deal with each incoming sample
> independently, for each one adding some sort of filter kernel into the
> table; or B: advancing sy
On Thu, Jun 14, 2012 at 2:41 PM, Miller Puckette wrote:
> I've been thinking about this for some days. I agree there are two
> fundamentally different approaches (A: deal with each incoming sample
> independently, for each one adding some sort of filter kernel into the
> table; or B: advancing sy
On Thu, Jun 14, 2012 at 2:56 PM, Charles Henry wrote:
> I'm not sure I understood the whole thread so far... let me back up:
>
> I'm not sure that you want to write samples of a function to the table
> for each sample you want to write.
>
> You start with two signals (blocks of N), one is the data
I'm not sure I understood the whole thread so far... let me back up:
I'm not sure that you want to write samples of a function to the table
for each sample you want to write.
You start with two signals (blocks of N), one is the data you want to
write, the other is the indexes where you want the v
Sorry, for 'gianl' below read 'signal'.
On Thu, Jun 14, 2012 at 11:41:01AM -0700, Miller Puckette wrote:
> I've been thinking about this for some days. I agree there are two
> fundamentally different approaches (A: deal with each incoming sample
> independently, for each one adding some sort of f
I've been thinking about this for some days. I agree there are two
fundamentally different approaches (A: deal with each incoming sample
independently, for each one adding some sort of filter kernel into the
table; or B: advancing systematically through the table, filling each point
by interpolati
On Wed, Jun 13, 2012 at 6:14 PM, katja wrote:
> There should be an (optional) amplitude compensation for up- and
> downsampling, as an amplitude effect would be inconvenient in the case
> of a variable-speed sound-on-sound looper.
>
> Katja
I think that a consideration here to justify a scaling
Been in touch with P.A. (he's my supervisor at Huddersfield) and he would
be delighted to have a Pd version of iPoke~. If we get a posse together,
or if someone is happy to take it on, he's more than happy to share the
source code with us/you/them/it. There's also a new version (v.3) which
hasn't
>> Two points here. The last thing you said is not actually true -- each
>> interpolation scheme has an associated convolution function, which can
>> be calculated by imagining what the interpolation would look like for
>> a single sample whose value was 1.0 surrounded by zeroes everywhere
>> else.
Ha, finally a detailed discussion on this topic, I like it. My replies
are inlined.
On Wed, Jun 13, 2012 at 10:27 PM, Matt Barber wrote:
> Hi, I've been going through the vdelayxw code myself. See comments:
>
> On Wed, Jun 13, 2012 at 12:30 PM, katja wrote:
>> On Sat, Jun 9, 2012 at 5:18 PM, Mat
On Wed, Jun 13, 2012 at 3:27 PM, Matt Barber wrote:
> I'm not sure I understand this - I assume you mean "very small
> increments in the written table." So lets say you're going to try to
> write a whole 64-sample input block to between indices 10 and 11 of
> the table. If you're writing 4 samples
Hi, I've been going through the vdelayxw code myself. See comments:
On Wed, Jun 13, 2012 at 12:30 PM, katja wrote:
> On Sat, Jun 9, 2012 at 5:18 PM, Matt Barber wrote:
>
>> Csound has a variable write delay opcode that would be worth looking
>> at - the csound website has just been flagged by go
On Sat, Jun 9, 2012 at 5:18 PM, Matt Barber wrote:
> Csound has a variable write delay opcode that would be worth looking
> at - the csound website has just been flagged by google for having
> malicious content so I can't link to the manual page, but the opcode
> is called "vdelayxw."
Unfortunat
Hi,
I was away from the list for a long while and missed the [tabwrite4~]
conversation -- quite interesting.
I have been thinking about this for a while. Depending on the
application, there's a further complication, which is whether it would
overwrite samples in the table, or mix the incoming sig
On Sat, Jun 9, 2012 at 11:00 AM, Georg Bosch wrote:
> things I used ipoke~ for in Max include an array/buffer based looper that
> allows for overdubs while changing playback speed, and pedal-style delays,
> where each feedback iteration is pitchshifted (see also discussion here:
> http://puredata
Am 06.06.2012 um 10:26 schrieb Roman Haefeli:
This somehow reminds of the thread about settable [receive]. Is there
really a need for the ability to do interpolated writing?
Conceptually,
is there any restriction if it is lacking? Can't everything that
employs
interpolated writing be achi
On Fri, Jun 8, 2012 at 9:18 AM, Roman Haefeli wrote:
> On Mit, 2012-06-06 at 11:07 -0400, Matt Barber wrote:
>> > On Wed, 2012-06-06 at 09:53 +0200, Jeppi Jeppi wrote:
>> > > Hey,
>> > > I wonder whether there is something similar to Max' ipoke~ (an
>> > > interpolating buffer~ writer) for Pd. I s
On Mit, 2012-06-06 at 11:07 -0400, Matt Barber wrote:
> > On Wed, 2012-06-06 at 09:53 +0200, Jeppi Jeppi wrote:
> > > Hey,
> > > I wonder whether there is something similar to Max' ipoke~ (an
> > > interpolating buffer~ writer) for Pd. I should need it for some
> > > physical modelling and resampli
- Original Message -
> From: Roman Haefeli
> To: pd-list@iem.at
> Cc:
> Sent: Wednesday, June 6, 2012 4:26 AM
> Subject: Re: [PD] ipoke~ ?
>
> On Wed, 2012-06-06 at 09:53 +0200, Jeppi Jeppi wrote:
>> Hey,
>> I wonder whether there is som
> On Wed, 2012-06-06 at 09:53 +0200, Jeppi Jeppi wrote:
> > Hey,
> > I wonder whether there is something similar to Max' ipoke~ (an
> > interpolating buffer~ writer) for Pd. I should need it for some
> > physical modelling and resampling stuff. Otherwise, I could implement
> > it myself. It seems o
On Wed, 2012-06-06 at 09:53 +0200, Jeppi Jeppi wrote:
> Hey,
> I wonder whether there is something similar to Max' ipoke~ (an
> interpolating buffer~ writer) for Pd. I should need it for some
> physical modelling and resampling stuff. Otherwise, I could implement
> it myself. It seems only interpol
Hey,I wonder whether there is something similar to Max' ipoke~ (an
interpolating buffer~ writer) for Pd. I should need it for some physical
modelling and resampling stuff. Otherwise, I could implement it myself. It
seems only interpolated reading is available (tabread4~ and similar ones), not
53 matches
Mail list logo
