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 provided to combine and split signal channels.
I've put a couple of example patches on http://msp.ucsd.edu/tmp/multichannel-tests.tgz ... the interplay between multichannel inlets and outlets and clone are sometimes amusing.
cheers Miller
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 < pd-dev@lists.iem.at> escreveu:
Not yet Matt, but maybe it could be twice as thick?
Em ter., 17 de jan. de 2023 às 01:28, Matt Barber brbrofsvl@gmail.com escreveu:
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 makes it happen with the '-d' flag, which is amazing! But in order to do this I have to copy a single input into a multichannel array with [pack~] and I wonder if this can be simplified by using yet a new flag where a single signal inlet~ can be distributed to all copies and a multichannel is output. Maybe not worth the hassle, but maybe it could be more significantly efficient? If it's not significantly efficient then it would be just a bit more convenient.
Em ter., 17 de jan. de 2023 às 00:24, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
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 and deal with it.
Another question is how to deal with this in externals :)
cheers
Em ter., 17 de jan. de 2023 às 01:30, Alexandre Torres Porres < porres@gmail.com> escreveu:
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 catch~/throw~. Also, if it's ever desirable for clone~ to distribute/repack things in chunks of more than one channel at a time, I guess inlet~/outlet~ will need channel arguments too. But I doubt there will be enough demand to justify doing that.
cheers M On Tue, Jan 17, 2023 at 01:33:50AM -0300, Alexandre Torres Porres wrote:
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 [mc.lores~]. I find this all a bit confusing and more complex than ideally.
Am I right to expect we'll just add multichannel support for all vanilla objects without having to worry about such complexity of adding a similar different creator/help files?
And it's fine if some objects need or would benefit with specifying number of channels, but may I propose we use a '-mc' flag for that? I'm thinking that maybe adding this extra argument to some object might be problematic (it wasn't with s~/r~) and better suited as a flag. Then, just for the sake of consistency, using '-mc' for all is better.
I can think of something like [osc~ -mc 4] which creates 4 channels and takes a multichannel signal to control the frequency of each oscillator. We can then also provide frequencies for all channels as arguments after the flag as well, like [osc~ -mc 4 400 500 600 700]. This would be very hard without a '-mc' flag.
cheers
Em ter., 17 de jan. de 2023 às 13:18, Miller Puckette msp@ucsd.edu escreveu:
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 case, I'd consider adding the possibility for the clone object to take the name of a primitive object (as opposed to a subpatch) - IF it's possible to design it well and simply. I wouldn't want to invent separate "mc~" versions of everything - that would be a nightmare.
cheers Miller
On Tue, Jan 17, 2023 at 02:30:44PM -0300, Alexandre Torres Porres wrote:
Em ter., 17 de jan. de 2023 às 14:54, Miller Puckette msp@ucsd.edu escreveu:
not sure of the internal challenge, but I would intuitively think of a list setting frequencies in this case (might be harder in other cases).
hmmm, I actually had thought about that before this multichannel thing for easilly creating a bank of oscillators, for instance. It could be a way for us to also create 'mc.' versions.
I wouldn't want to invent separate "mc~" versions of everything - that would be a nightmare.
+1
cheers
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 file of pack~/unpack~ if called from [unpack~] - https://github.com/pure-data/pddp/issues/130 - and added a multichannel example to [send~]/[receive~]. I also revised a few things. Please check and revise yourself.
I still didn't change the documentation of [inlet] to include a multichannel example but it's the next thing on my list, so you may wanna wait for that and this is just a heads up. We can take a bit more time on [clone], before we rename flags and see what new things it might do or not.
Cheers
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. Is it implemented as some additions to the MSP signal compiler — the code that turns a graph of MSP objects into an ordered sequence of operations on signals — to deal with patch cords that hold more than one audio signal (...) if you want your MSP object to have outlets that produce multi-channel signals, you will have to change the type of the outlets from signal to multichannelsignal. An outlet of type multichannelsignal (...) A patch cord coming from this type of outlet (...) can be connected to any MSP object, even those that don’t know about MC. (In that case, only the first channel will be used.) (...) The MC wrapper looks at the name the user types, removes the “mc.” from the beginning, and looks for a Max object with the string that remains (...) The name “myfilter~” at the end of this message specifies the name of the help file to open. If you want to make a special help file for the N-way version of your object, you could do (...)
---------------------------------------------------------------------------------------------
so it seems they did not create new codes and new objects, just adapted, and even made it possible for it to open a special help patch but it's all the same object and you can use this API to generate externals - if I get things correctly...
cheers
Em ter., 17 de jan. de 2023 às 21:45, Alexandre Torres Porres < porres@gmail.com> escreveu:
On Tue, Jan 17, 2023 at 01:30:19AM -0300, Alexandre Torres Porres wrote:
This is possible using "-do" (distribute outputs) in which case inlet~s are passed in unchanged.
OTOH, there's no good way to make a clone~ object in which some inlet~s are distributed and others are passed unchanged, or similarly with outlet~s....
Incidentally, now I think the word "distribute" is ambiguous - does anyone have a better word for packing/unpacking on way in and out of clones?
cheers Miller
Em ter., 17 de jan. de 2023 às 13:21, Miller Puckette msp@ucsd.edu 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 insted of 'straightthrough' and I just added a [+~ $1], so I'd add a value to each channel according to the instance number. I did expect it to ignore other channels but it didn't work and it complained that [+~] couldn't handle multichannel. But a single input signal does really work and this is quite cool and amazing :) really happy I can already mess with this.
Incidentally, now I think the word "distribute" is ambiguous - does anyone have a better word for packing/unpacking on way in and out of clones?
fan-in/fan-out? ('fi', 'fo')
cheers
Am 17. Jänner 2023 17:21:38 MEZ schrieb Miller Puckette via Pd-dev pd-dev@lists.iem.at:
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 mentioned in the comments. I would have suggested something along the lines of "multichannel" (that is: '-m'), but Alex's fan-in/out makes sense as well...
mfg.sfg.jfd IOhannes
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) 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: the following members are private - DO NOT USE")
- since the t_signal members now have a bit of documentation, could we just mention that s_sr has the overlap-factor pre-multiplied? (assuming this will stay that way - which is most likely for backwards compatibility)
- why do we need a "class_setdspflags()"? (i'm not opposed; merely wondering) shouldn't those flags just go into class_new()? is it for symmetry with class_getdspflags() which in turn is required to not expose the internals of t_class? but then: d_ugen.c could already just directly access t_class (via m_imp.h), and i wonder whether an external would ever need the class_getdspflags() (or at least, an external that doesn't otherwise need to access private data from m_imp.h)
- isn't CLASS_NOPROMOTELEFT somewhat redundant? e.g. the code could just check whether there's an explicit "float" method for the class, and if so automatically declare to not promote signals on the left.
- [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 of *any* VCS; but the copyright boilerplate says 2000/09/01 and i have no reason to distrust it). so i expect that either old patches that use zexy's [pack~]/[unpack~] are going to break, or the new multichannel [pack~]/[unpack~] won't be usable if zexy is loaded as a multi-object library.
vmgs IOhannes
On 1/17/23 08:32, IOhannes m zmoelnig wrote:
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 this doesn't matter much for specialized objects that only make sense in a multichannel context, but i imagine it would often be nice to upgrade singlechannel objects as well.
gfdmast IOhannes
Quick responses to below...
Good idea, and this needs to be a more general strategy somehow.
yep. I was even thinking of putting "overlap" as a separate (public) member, but then again i couldn't think of how to use it compatibly in vanilla objects so ended up not doing it. But if that would be useful perhaps I should add support.
This is so that externs can call "class_setdspflags()" explicitly if they use the new features - older pd versions won't load them and crash.
The use case is a bit rare... if someone puts a scalar in the left inlet of a binop (like zero into "-" to negate a number) this allows the binop to use a scalar operation and save a wee bit of compute time. Not sure if this is ever going to matter.
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~. The best solution I can think of is to either find a different (unused) name for the new pack~/unpack~ or to offer a new name to zexy's versions (and keep the old ones too, perhaps in a separate "library").
vmgs IOhannes
Em ter., 17 de jan. de 2023 às 14:26, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
That's not really true. What happens when zexy or any other external is called with the same name as an internal object is that Pd renames is and creates an alias for the old one. This used to be printed in the console at level '2 normal' but now needs a higher level (and I don't know why, seems like an important *normal* message).
In fact, zexy already aliases and replacs [abs~], which is ok because it offers the exact same functionality, but you can still creat pd vanilla's as [abs~_aliased], same would be true for [pack~_aliased] and [unpack~_aliased], but yeah, that would be a pain.
There were issues in Cyclone as well and we found a way to keep the name and not clash. We force and allow using things like [cyclone/line~] (called from a single binary) without clashing with vanilla's [line~] - we allow something like [cyclone/>~] (loaded from a library) which prevents clashing with zexy's [>~]. Maybe zexy could do something like this, but old patches that use zexy's pack~ would not work in new Pd Vanilla versions as they'd call the new vanilla objects instead. In this case, maybe a warning when loading a new version of zexy that pack~/unpack~ needs the 'zexy' prefix solves it.
For reference; Cyclone objects that don't clash with vanilla objects: append, pow~, line~, clip, clip~, table and snapshot~ https://lists.puredata.info/listinfo/pd-dev cheers
On 1/17/23 17:13, Miller Puckette via Pd-dev wrote:
if possible i would like to avoid that.
The best solution I can think of is to either find a different (unused) name for the new pack~/unpack~ or
i would prefer this. howe about the [split~]/[merge~] pair suggested by Jean-Yves?
to offer a new name to zexy's versions (and keep the old ones too, perhaps in a separate "library").
i'm mostly concerned about embedding old abstractions (that use zexy's [unpack~]/[pack~]) that are to be embedded in new patches (that want to use multichannel capabilities), so the two should be able to co-exist.
in retrospect i wouldn't have named the zexy objects like i did, but i was young and needed the money.
gmdasr IOhannes
On Mon, 2023-01-23 at 08:40 +0100, IOhannes m zmoelnig wrote:
i would prefer this. howe about the [split~]/[merge~] pair suggested by Jean-Yves?
I think those are more descriptive names, regardless of the name collision problem.
+ 1
I don't think 'pack~' and 'unpack~' fit any less to what zexy's objects do. Like their non-tilde counterparts, they pack to lists und unpack from lists. I think those names are quite good.
Roman
I actually do like pack~/unpack~ a lot, because they have control counterparts and also MAX uses something similar but prepends 'mc.' to it, so [mc.pack~] and [mc.unpack~] are exactly what [pack~] and [unpack~] do!
On the other hand, if we really want to avoid this collision badly, maybe we could use a similar convention to specify an object that is multichannel aware, something quite new in the pd world. I'm not saying we should use the same 'mc.' convention. I know using "." is not much common in the Pd world, but in ELSE I use it and have plans to add many multichannel aware externals that would make things simpler and while we don't have our [clone] solution for internal and external objects, like a muti channel [dac~] object called [dac.mc~]. I like it better that the mc comes later as objects would be alphabetically next to their multichannel version. This would also prevent people from thinking it's an external from Cyclone that mimics the original.
So... what about [pack.mc~] and [unpack.mc~]?
maybe just [packmc~] and [unpackmc~] as well... but I like "."
cheers
Em seg., 23 de jan. de 2023 às 06:38, Roman Haefeli reduzent@gmail.com escreveu:
How about "snake~ in" and "snake~ out" ... assuming a "snake" is easily enough understood as a multichannel audio cable?
Or tosnake~ / fromsnake~ or even snake~ and unsnake~ ?
cheers M
On Mon, Jan 23, 2023 at 09:02:33AM -0300, Alexandre Torres Porres wrote:
I find snake~ and unsafe~ a bit weird but amusing, I kinda like idea of typing that object name and read it in a patch
On Mon, 23 Jan 2023 at 18:49 Miller Puckette msp@ucsd.edu wrote:
I was also going to suggest snake~ as the accepted hardware metaphor. I think it would maybe be snake~ and breakout~ if taken literally.
In order to make in/out clear, it might be insnake~ outsnake~
bundle~ unbundle~ would also be an intuitive choice.
Whatever it ends up being, I think there definitely needs to be a visual clue that the connection is multichannel, and maybe to reveal the number of channels on hover in edit mode for clarity and debugging (especially in deep patch nesting)
On Mon, Jan 23, 2023, 4:54 PM Alexandre Torres Porres porres@gmail.com wrote:
I think the proposal join~/split~ is the one I prefer. It follows quite well the naming of other pairs like throw~/catch~ or send~/receive~. Just a personal feeling...
Antoine
Le mar. 24 janv. 2023 à 08:25, Matt Barber brbrofsvl@gmail.com a écrit :
About the debugging suggestion, what about enhancing [nop~] to became graph on parent with one number box showing the number of channels?
this way we can select a connection and do Ctrl + t (triggerize) and get a [nop~] showing a number box inside
it of course needs to show its name, so we can edit [nop~] to create another object if needed, but as a fast way to know the number of connections i think it would be an interesting user experience
Em ter., 24 de jan. de 2023 06:17, Antoine Rousseau antoine@metalu.net escreveu:
sorry for double posting, but for my idea to work i think [inlet~] should receive an outlet that gives the number of channels, this makes trivial to then update [nop~] to give the functionality i mentioned
Em ter., 24 de jan. de 2023 07:20, José de Abreu abreubacelar@gmail.com escreveu:
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 is a bit long, but I tried to write as concisely as possible, so please keep reading :-)
---
There are few things in the API that I think could be streamlined a bit.
1) Currently, external authors have to explicitly create the output signals if they want the object to be multi-channel aware. For example, here's the relevant line in plus_dsp():
sp[2] = signal_new(nullsignal->s_length, outchans, nullsignal->s_sr, 0);
Now, most of this information is redundant. I cannot imagine a situation where you would provide a different vector size or samplerate. The only thing we are really interested in is the number of channels.
Instead of creating the signal, I would rather prefer the following:
signal_setchannels(sp[2], outchans);
IMO, this would be much more descriptive and also reduce the chance for mistakes.
---
2) "dsp" methods now have an additional "t_signal *nullsignal" parameter for cases where you cannot get the vector size otherwise (except by going through the owning canvas). Typical example: multi-channel objects with no signal inlets (because the output signals are yet to be created).
Actually, the introduction of signal_setchannels() - see above - would make this obsolete because you would't need to create signals in the first place! The only remaining use case for the "nullsignal" would be an object with no signal outlets and where all signal inlets are "scalars" (= float to signal promotion is turned off). This is quite an edge case, though, and I cannot think of an example in the Pd core...
On the other hand, I kind of like this extra parameter because it provides a /uniform /way to access shared DSP parameters. However, I would suggest to make a proper structure instead of reusingt_signal, e.g.:
typedef struct _dspinfo { d_blocksize; /* number of items per channel */ t_float d_sr; /* samples per second per channel */ int d_overlap; /* overlap factor */ int d_nin; /* number of signal inlets */ int d_nout; /* number of signal outlets */ /* ... anything else? */ } t_dspinfo;
Note that we can take the chance to pass some extra info that is not part of t_signal, such as the number of signal inlets and signal outlets.
---
3) IMO, class_setdspflags() should be used consequently in the codebase instead of passing the DSP flags to class_new(). It is not strictly necessary, but it would set a good example to external authors.
As Miller explained, the main reason for class_setdspflags() is that externals using these new feature would refuse to load in older Pd version; otherwise they would just crash.
---
4) Whenever an object requires you to set the number of channels explicitly, e.g. in [send~]/[receive~]/[throw~]/[catch~], there should be a way to change the number of channels with a message!
For example, if I have an ambisonics patch, I would like to be able to change the ambisonics order (and hence the channel count) on the fly.
This can be implemented easily, you just need to update the DSP graph after changing the number of channels.
---
5) Regarding the naming of [pack~]/[unpack~]: I don't have a strong opinion. On the one hand it corresponds nicely to what [pack] and [unpack] does, on the other hand it clashes with the zexy library...
[split~] and [join~] are not bad, but I think they would fit better to a different kind of object (see below).
I find [snake~] and [unsnake~] quite funny :-)
---
6) Regarding the [clone] discussion: I very like the idea of creating embedded abstractions or even accepting compiled objects! I often thought about this myself.
I also think it would also be nice to have something like [mc~] as an alias for [clone -x -d] because the latter is not exactly obvious.
---
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.
* [join~] (or [merge~], etc.): take several multi-channel signals and combine them as a single (multi-channel) signal. (Actually, the same functionality could be achieved by a more generalized version of [pack~] that also deals with multi-channel input signals.)
---
8) Ideas for existing objects:
AFAIU, the plan is to make all math objects multi-channel aware, but not touch any "stateful" objects, such as filters or oscillators. Generally, I agree with this!
Some random objects that could be made multi-channel aware:
a) [sig~], i.e. [sig~ 0.1 0.5 0.7 0.8] would output a 4-channel signal.
b) [snapshot~]. If the input is multi-channel, it would sample all channels and output them as a list. This would be quite handy for metering multi-channel signals :-)
c) [print~], with nice formatting!
d) [expr~] and [fexpr~] :-)
---
Thanks for reading :-)
Christof
On 17.01.2023 04:23, Miller Puckette via Pd-dev wrote:
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 info@christofressi.com escreveu:
Em ter., 24 de jan. de 2023 às 21:58, Christof Ressi info@christofressi.com escreveu:
it'd be nice to split more than just two, like MAX's [mc.separate~]
just for reference, that's MAX's [mc.combine~]
a) [sig~], i.e. [sig~ 0.1 0.5 0.7 0.8] would output a 4-channel signal.
+1 and it could take a list input as well to update values (like the [mc.list~] clone I was trying to code).
d) [expr~] and [fexpr~] :-)
of course :)
Thanks for reading :-)
thank you
Howdy, I just released Cyclone 0.7-0 and I'm saying it needs at least 0.53-2, which there's already a test version out. It's been there for a while actually and I wonder if we'll have a stable release update soon. I'm also planning to release an update of ELSE next week and tell people to get it.
Cheers
Am 23. Februar 2023 18:14:23 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
Howdy, I just released Cyclone 0.7-0 and I'm saying it needs at least 0.53-2, which there's already a test version out.
For an important library like "cyclone" I would welcome it, if it supported *at least* the last two stable releases (currently: 0.52.*, 0.53.*), and ideally something like the last 5 years.
mfg.sfg.jfd IOhannes
This is always "minimal". Cyclone has a [number~] abstraction that has been in there for about 6 years. Thanks to 0.53 it can now print 'nan', this is why 0.53 is required now.
ELSE comes with a tutorial that is always up to date with latest Pd, so it mentions how you can change the orientation of sliders, this sort of things... sometimes it's more relevant, like when 0.54 multichannel is out, ELSE will surely make use of these capabilities.
Em sex., 24 de fev. de 2023 às 05:57, IOhannes m zmölnig zmoelnig@iem.at escreveu:
On 2/24/23 14:35, Alexandre Torres Porres wrote:
so that's why you are "saying [that] it needs at least 0.53-2"?
i'm sure there are people out there who think that not being able to print "nan" is a serious error, but i doubt there are many :-)
ELSE comes with a tutorial that is always up to date with latest Pd, so it
i was talking only about cyclone. no idea why ELSE came in (we can talk about ELSE once it stops breaking the interface between minor releases :-))
gmards IOhannes
On Fri, 24 Feb 2023 at 10:43 IOhannes m zmölnig zmoelnig@iem.at wrote:
Yup. Otherwise you’ll open the help file and think there’s a bug.
i'm sure there are people out there who think that not being able to
You mentioned important libraries like cyclone, I thought ELSE would apply :)
we can talk
Yup. Otherwise you’ll open the help file and think there’s a bug.
But that does not really mean that cyclone as a whole *requires* Pd 0.53-2. It is really a minor issue. If you say "cyclone requires Pd 0.53-2", then people will think that it does not work at all with older Pd versions and might be hesitant to upgrade.
Instead you could explicitly mention this particular issue (and others?) in the help patches or release notes.
Christof
The changelog (a kind of release note) is clear about it
On Fri, 24 Feb 2023 at 11:23 Christof Ressi info@christofressi.com wrote:
On 2/24/23 16:33, Alexandre Torres Porres wrote:
The changelog (a kind of release note) is clear about it
fine. but would you, as an avid Pd-0.52-4 user (who currently cannot afford to upgrade) download cyclone-0.7.0 which was announced as "requires Pd-0.53-2" (so you kind of know that it won't work for you), then go and find the ChangeLog within the package just to see that indeed Pd-0.53-2 is not required unless you open one of the help-patches and also notice that in some circumstances (which are best avoided in any case) one of the objects shows a wrong number?
how about instead adding a note to your help-patch that says:
NOTE: On Pd<0.53-2 NaN-values are not displayed properly?
and then stop announcing the requirement on Pd>=0.53-2?
gmadsr IOhannes
In relation to the original topic discussion, it seems miller has finished 0.53-2 and is having a hard time announcing to the Pd list and uploading it to his site, this came up on github messages.
In the meantime, I released ELSE, which theoretically also depends on 53-2 (and it seems it's fine in this case). Also, in the meantime, someone complained that he installed the latest cyclone and [scope~] "wasn't there", or was broken. The truth is that he was using 0.51 and the code now uses a recent 'undo' for GUIs introduced in 0.52. So it seems I can maybe not say it actually "needed" 0.53, but I wouldn't go lower than 52! The thing is I just asked him to upgrade to 0.53 and he gladly did.
I usually see people just sticking to old versions of Pd just because they don't really follow up that much. There's no automatic version check or warnings for people to upgrade and stuff. I wouldn't know why someone would not upgrade to the latest version as this is something I always did and never had an issue. I get the deal of being careful in upgrading your software, but Pd feels very safe... occasionally there are some regression bugs, but serious stuff get fixed quickly and something like that happened in from 0.53-0 to 0.53-1, and the latest version is the safe one if you have the latest macOS.
I'm not saying there may not be any issue ever. I'm just saying I have this experience and I'm not quite aware of the need to hold back to previous versions. I'm curious to hear more about it though. I can say that similar things have happened before, with people complaining about an issue or a bug and me telling them they needed to upgrade, no one ever complained they coudn't.
The thing is, I can't change the past. Packages are uploaded and they have this warning. I've been careful in always stating that people needed the version. I can think of a better and more detailed way to say things. I agree that saying it "needs" the latest version is misleading. The thing is that giving too much details seems not a good idea either. Let me think...
But anyway, like I said, if anyone doesn't want 0.53 for some reason, 0.52 is the minimum version for a reasonable support for cyclone 0.7-0.
Cheers
Em sex., 24 de fev. de 2023 às 14:04, IOhannes m zmölnig zmoelnig@iem.at escreveu:
On 3/6/23 05:53, Alexandre Torres Porres wrote:
for "standalone" users this is probably true. for corporate users i think this often boils down to in-house policies.
e.g. in university labs the machines are often administered by some central authority that is not especially Pd affine (they just manage software in general). they tend to not always update machines immediately after one of the components has been updated. and even if they do, they often only update during the semester breaks (and not during a running semester).
then there is also the issue of operating systems that already come with Pd (preinstalled, or in the OS repositories), like Ubuntu or Debian.
it might not be your modus operandi, but it's nice to think of others.
gmasdr IOhannes
Hi Miller, I'm trying a new message to follow up on this, you said you had 0.53-2 stable version out on github, but emails weren't coming through to announce it though, for reference --> https://github.com/pure-data/pure-data/pull/817#issuecomment-1455105810
but in http://msp.ucsd.edu/software.html I still see *TEST** RELEASE, version 0.53-2test1*
I then went to "all downloads" and found *53-2*, see --> http://msp.ucsd.edu/Software/pd-0.53-2.macos.zip - but it unpacks to "Pd-0.54-0test1-8-gef40e147"!
Sorry to insist, just wanted to make sure the release is final and through so I can announce it on facebook/etc...
cheers