> naming of [pack~]/[unpack~]
Maybe they also could be called:
[group~]/[ungroup~] ?
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
Em ter., 24 de jan. de 2023 às 21:58, Christof Ressi
escreveu:
> 7) Ideas for new objects:
>
> * [split~] (or [moses~], etc.): take a multi-channel signal and split it
> into two different multi-channel signals at the specified channel offset.
>
it'd be nice to split more than just two, like
> I find [snake~] and [unsnake~] quite funny :-)
I'm glad I'm not the only one :) and usually Pd has some funny names, so it
felt quite proper to me ;)
Em ter., 24 de jan. de 2023 às 21:58, Christof Ressi
escreveu:
> Hi all,
>
> I am a bit late to the party. I finally got around studying the
Hi all,
I am a bit late to the party. I finally got around studying the new
multichannel code changes and wading through this massive sea of e-mails
to get up to date on the discussion :-)
First off, I am very excited about this new feature! Here are a few
comments from my side. The e-mail
Em qui., 19 de jan. de 2023 às 05:04, IOhannes m zmoelnig
escreveu:
> afaict the idea is to get rid of this abstraction altogether, and be able
> to just use
> [clone -di -s 1 dac~ 16]
>
yeah I guess it was pretty late and I was tired and I couldn't see how this
could actually make [dac~] get
Without reading your reply in depth, it calls to mind my feeling that it would
be *nice* if somehow clone supported subpatches natively to avoid requiring
abstractions for simple things ala:
[clone pd …]
This is probably another discussion, however.
enohp ym morf tnes
---
Dan Wilcox
On 1/19/23 07:02, Alexandre Torres Porres wrote:
So, being able to call internal objects inside [clone] saves us the need to
write a simple abstraction for this or any other object, which is good, but
how would I be able to set the argument of [dac~] in [clone] and have it
receive the instance
but anyway, I have a few doubts how [clone] would deal with internals, and
this is just a rough idea so far, and we'll have to better discuss this
when time is right...
for instance, how would someone deal with arguments?
Like, I made a simple abstraction to mimic somewhat MAX's [mc.dac~], which
On 1/17/23 20:55, Dan Wilcox wrote:
fan-in/fan-out? ('fi', 'fo')
I also thought of "fan in" and "fan out" ... probably to the consternation of IOhannes
who added the "triggerize" feature. ;)
not at all.
i hate message fan outs, but i think we are talking about signals here.
mgfd
Cool, yeah, it would be ideal if it could also load externals somehow ;)
Em qua., 18 de jan. de 2023 às 11:45, Dan Wilcox
escreveu:
> I can't answer you as I haven't looked at Miller's implementation. I can
> *imagine* that if [clone] is able to load an internal class then it follows
> it would
I can't answer you as I haven't looked at Miller's implementation. I can
*imagine* that if [clone] is able to load an internal class then it follows it
would be able to open an external class which is loaded. I didn't mean to imply
that it can *now* but more than it *might* be able to if it can
Em qua., 18 de jan. de 2023 às 05:18, Dan Wilcox
escreveu:
> Also similar to Miller's approach, there appears to be a way to load
> existing mono externals in the mc mechanism. So yeah, same problem, similar
> technical solution, different implementation.
>
Hmm, I am still missing what is Pd's
> On Jan 18, 2023, at 2:41 AM, pd-dev-requ...@lists.iem.at wrote:
>
> "MC is not an entirely new API for MSP objects. Instead it is built on top
> of the existing MSP API. (...)
This name prefix / wrapper approach seems like an implicit way of what Miller
is looking at doing more explicitly
So, for reference and inspiration, In Max "MC" is a wrapper that can be
applied to any dsp object. see
https://cycling74.com/sdk/max-sdk-8.2.0/chapter_mc.html
for details. I quote from it below:
"MC is not an entirely new API for MSP objects. Instead it is built on top
of the existing MSP API.
Em ter., 17 de jan. de 2023 às 20:55, Alexandre Torres Porres <
por...@gmail.com> escreveu:
> I still didn't change the documentation of [inlet] to include a
> multichannel example
>
ok, now I did it :)
___
Pd-dev mailing list
Pd-dev@lists.iem.at
Dear Miller, please consider checking and merging my documentations branch
- https://github.com/pure-data/pure-data/pull/1856 . There aren't that many
new things since the last release and I have already fixed issues regarding
the new multichannel stuff, like Pd not being able to load the help
Am 17. Jänner 2023 17:21:38 MEZ schrieb Miller Puckette via Pd-dev
:
>
>Incidentally, now I think the word "distribute" is ambiguous - does anyone
Incidentally I had a hard time figuring out what that "-d" flag was supposed to
mean (without reading the sources), even though it is oh course
I'm fine with objects like [osc~] not being multichannel is there is an easy
way to parallelize / multiplex instances ... ie. clone. For consistency, one
might want the Max approach of providing alternate versions of *all* dip
objects, but if that's too much code overhead and we can concentrate
Em ter., 17 de jan. de 2023 às 14:54, Miller Puckette
escreveu:
> The trouble with multichannel osc~ (etc.) is to figure out how to
> distribute
> messages setting frequency and phase, etc., to the individual copies.
>
not sure of the internal challenge, but I would intuitively think of a list
Em ter., 17 de jan. de 2023 às 14:26, Miller Puckette via Pd-dev <
pd-dev@lists.iem.at> escreveu:
> Hmm... well, old patches should run OK if the lib is explicitly loaded.
> But it's a bother that new patches that pull zexy in explicitly won't
> be able to use pack~ and unpack~.
That's not
So far all I'm thinking of is to make "+~" etc. be multichannel but leave
the rest (the ones that have internal state) as single-channel only.
The trouble with multichannel osc~ (etc.) is to figure out how to distribute
messages setting frequency and phase, etc., to the individual copies.
In any
I see there will not be a rule then on having to specify number of channels
in all objects.
Well, I don't use MAX and haven't checked their multi channel stuff in
depth, but I guess "all" MSP objects have this support if called with
"mc.", and there's a different help patch for, say, [lores~] and
Quick responses to below...
>
> - the size of t_signal has changed. i think this is fine, as the trailing
> members (affected by the change) are private only. i wonder though
> whether this privateness should be made more explicit in the m_pd.h
> (basically: add a line saying "hic sunt dracones:
Em ter., 17 de jan. de 2023 às 13:21, Miller Puckette
escreveu:
> This is possible using "-do" (distribute outputs) in which case inlet~s
> are passed in unchanged.
>
I see it now, I couldn't get it to work but I was trying a multichannel
input into it with [pack~]. I was trying a simple patch
On Tue, Jan 17, 2023 at 01:30:19AM -0300, Alexandre Torres Porres wrote:
> Wow, [clone]'s nem multichannel functionalities are quite cool and amusing
> indeed. I always wanted to be able to have [clone] output parallel
> processing - like having white noise being filtered in parallel with a
>
It turned out that having send~/receive~ detect channel counts would have
necessitated replacing the whole ugen sorting system with a two-pass one,
so that when each is scheduled it can find out about the corresponding
ones. So it was too heavy a chenge to pull off.
The same will be true for
Message: 4
Date: Tue, 17 Jan 2023 08:32:35 +0100
From: IOhannes m zmoelnig
- [pack~] and [unpack~] are of course natural names for these objects.
*unfortunately* i have added objects of the same name (but with
different functionality) to zexy about 23 years ago. (the objects
predate zexy's use
On 1/17/23 08:32, IOhannes m zmoelnig wrote:
- why do we need a "class_setdspflags()"? (i'm not opposed; merely
wondering)
sidenote: the current API prevents external binaries to support both
multichannel and older versions of Pd (obviously without multichannel in
this case).
i imagine that
On 1/17/23 04:23, Miller Puckette via Pd-dev wrote:
To Pd dev -
I've pushed what I think is working support for multichannel signals.
this is huge.
thanks a lot.
random thoughts:
- the size of t_signal has changed. i think this is fine, as the
trailing members (affected by the change)
Em ter., 17 de jan. de 2023 às 00:51, Alexandre Torres Porres <
por...@gmail.com> escreveu:
> Awesome
>
> I'm trying it but I packed two signals with pack~ and connected into lop~
> and got the error: object lop~ can't take multichannel inputs
>
> so it seems lop~'s multichannel
Now, as I see, [send~] and [receive~] need an extra argument to set the
number of channels. I wonder if all objects will end up having arguments or
if you just think this is a nice feature for s~/r~
My idea is that the object could just see how many channels there are in
the multichannel array
Wow, [clone]'s nem multichannel functionalities are quite cool and amusing
indeed. I always wanted to be able to have [clone] output parallel
processing - like having white noise being filtered in parallel with a
filterbank and then having access to each output instead of the sum. This
finally
Not yet Matt, but maybe it could be twice as thick?
Em ter., 17 de jan. de 2023 às 01:28, Matt Barber
escreveu:
> Are regular signal connections visually distinguished from multichannel
> connections?
>
> Thanks,
> Matt
>
> On Mon, Jan 16, 2023 at 10:24 PM Miller Puckette via Pd-dev <
>
Are regular signal connections visually distinguished from multichannel
connections?
Thanks,
Matt
On Mon, Jan 16, 2023 at 10:24 PM Miller Puckette via Pd-dev <
pd-dev@lists.iem.at> wrote:
> To Pd dev -
>
> I've pushed what I think is working support for multichannel signals. Many
> objects
Awesome
I'm trying it but I packed two signals with pack~ and connected into lop~
and got the error: object lop~ can't take multichannel inputs
so it seems lop~'s multichannel functionality isn't up yet?
cheers
Em ter., 17 de jan. de 2023 às 00:24, Miller Puckette via Pd-dev <
To Pd dev -
I've pushed what I think is working support for multichannel signals. Many
objects haven't yet been adapted to deal with them, but there are enough to
at least test the concepts: lop~, send~, receive~, and (ugh) clone are
multichannel-aware, and new pack~ and unpack~ objects are
36 matches
Mail list logo
