Pure data 0.48 released

[thetechnobear]

looks like 48 is now marked as ‘stable’, perhaps a discussion on if/when organelle should jump.
(note: its not packaged on pacman yet. so early discussion)

(EDIT : confirmed, though not updated on puredata.info yet, its been announced on pd-annouce as an official release)

http://msp.ucsd.edu/software.htm

release notes are here:
http://msp.ucsd.edu/Pd_documentation/x5.htm#s1

organelle is on 46
from 47, I think clone is a real bonus, and perhaps deken?
from 48

The Pd API allows starting and/or shutting down the GUI dynamically while Pd is running.

as mentioned by @oweno looks interesting,
but ive just downloaded 0.48 and can find no changet to the api for this…
I basically did a diff on m_pd.h from 47, and nothing was there, also I did find two references to sys_startgui sys_stopgui in the ‘private api’ , but they didn’t appear to the right thing to use, or useful.
(and a comment in one place saying, if its stopped, there is an issue restarting it)

another interesting change is, and I think perhaps related…

But the biggest changes are under the hood. Pd now can manage more than one running instance, so that it is possible to make plug-ins of various sorts out of Pd and they can coexist with each other. This will allow people to write much better VST plug-ins in Pd. I’m grateful to Carlos Eduardo Batista for much help on this.

this could be useful for Organelle potentially for running multiple patches? (though I have other ideas for that ) …
I’m wondering if this is more useful in a libpd context, which I think might be an interesting development for Organelle?
thoughts?

other good things in 47 48?

also I’m new to Pd, how stable are the zero releases? (e.g. 0.47.0) or do most wait for a 0.0.1 release, for initial bug fixes?

EDIT: sys_startgui
https://lists.puredata.info/pipermail/pd-dev/2017-07/021128.html
so this implies, its designed for libpd, which makes sense… and explains why its a pd api function.
(don’t understand why its not in m_pd.h, so id say is ‘private’, but perhaps that’s common )
I guess, id have to write a quick external to work out, if the PD executable is going to go bang, if you call it…
but as mentioned before, I’m quite interested in the idea of using libpd from the mother exec… if we did that, then this new feature, would still enable the UI to be brought up… say from a menu on in mother exec.
(hmm, I think we need another name for the mother exec, its too easy to confuse with mother.pd… perhaps if we move to libpd, it can be motherhost ;))

[Jaffasplaffa]

@thetechnobear

But the biggest changes are under the hood. Pd now can manage more than one running instance, so that it is possible to make plug-ins of various sorts out of Pd and they can coexist with each other. This will allow people to write much better VST plug-ins in Pd. I’m grateful to Carlos Eduardo Batista for much help on this.

Yes this i am really interested in this too. Couldnt find any documentation on how it works. But Miller said they are working on it.

And yes newest version seems pretty stable. I tried everyone of the test release and all of them had issues. But this new one seems to be good

[Wannop]

Very intriguing Feeding one patch to another, then another. Imagine!

[shreeswifty]

please be aware that 48 and those features to a large degree are for the desktop version. The big addition i see is that the installation of externals is becoming easier and helping the transition for many folks form extended to Deken

[wo3]

How is having multiple instances different than [pd~]? Does this mean pd can be multi-threaded easier now?

[Jaffasplaffa]

@shreeswifty

desktop version

What does desktop version mean @shreeswifty?

Thanks!

[thetechnobear]

Ive not played with this yet, but I suspect the key phrase is “plugins <blah , blah> coexist with each other”

pd~ as its launched by a pd instance, allows pd to have a master-slave relationship ie. the instantiating instance could be known by the master.

that can’t happen with Pd VSTs (such as pdVst) as the instantiator is the host (aka daw) which has no knowledge of PD,
so in turn these pd instances would be unknown to each other.
I suspect this change allows them to know about other instances, probably via a local udp broadcast message
(Im not sure why they want this, perhaps this has caused issues in the past, but not found anything in the mailing lists)

as i say this, just my thoughts/assumptions, until I check the code and start playing with it I wont know.

it should be noted, though, this is not just about VSTs at all… VSTs are a subset of use cases, this is more generally about applications/processes that use libpd - this is why potentially it could be useful for Organelle.

Organelle already has a ‘mother process’ which is the process has the menus, and is used (currently) to start PD.
this could be changed, so that instead of launching PD, instead it could directly load patches using libPD… this would allow tighter integration, including sending messages directly into the patch , rather than having to use OSC.

anyway, even with that said, as the mother process knows about pd/libpd, it probably wouldnt have the same issue as a vst host, but hey until we try and see we wont know

[shreeswifty]

A non wine VST host would be cool, I built the DSSI~ external but I am getting crashes presently is anyone here using DSSI~?

[jtjohnson]

I was away from my Organelle for a bit, and from my laptop I recently made a really cool patch on 0.48. Of course, at the heart of this patch I managed to use some objects that weren’t part of 0.46 / on the organelle.

I’m not new to the world of Pd/Max, but very very new to the world of Linux/embedded programming. Some posts above mentioned that a lot of Pd 0.48 would perform better outside of the Organelle, but is it possible to update to 0.48 on the Organelle somehow? or at the very least some guidance to figuring out how to compile the needed objects for the Organelle’s 0.46?

[thetechnobear]

I’ve compiled, and I’m running 0.48 on the organelle.
I’ve supplied this image to C&G and I hope/think it will be part of the next release.

Note: There were some minor issues with some patches, but these are now resolved.

[oweno]

curious, what new objects did you use?

[shreeswifty]

yeah, i was not aware of new objects included in 48

[thetechnobear]

there are a couple of new ones, and some updates to existing , but not many

The expr family (expr, expr~, fexpr~) got an update from Shahrokh Yadegari, and the help file was reorganized and updated by Alexandre Porres. Many more math functions are supported, and the parser was updated so that expressions using “if” skip evaluating the argument that isn’t used.

New “fudiparse”, “fudiformat” objects.

New “list store” object for faster and easier concatenation and splitting apart of lists.

New notification outlet in “text define” so the patch can know when the text is changed.

New “text insert” object.

“delwrite~” now has a “clear” message.

that said, for me, really I just want clone from 47.1, and there is no reason to go to 47, now its replaced by 48.
(my testing has shown 48 is perfectly reliable… once the master-metronome from c&g was ‘fixed’)

[shreeswifty]

i knew about the expr/fexpr updates that Shahrokh was making that’s cool.
I am getting a weird error in mone patch with the floor in an expr~ equation
but the code is ancient so i am sure i am out of luck

[wo3]

Curious about the errors in master-metronome for 0.48.

I haven’t really dug into clone yet because Organelle is still on 0.46.

[thetechnobear]

@wo3

Curious about the errors in master-metronome for 0.48.

some of the versions master-metro, send midi clock out from the very moment the patch is loaded - there is an issue in 0.48, that this clock message is sent before the output device has been initialised , and so PD crashes.

I’ve changed this in my versions, so clock is started to be sent a few milliseconds after the patch is loading, so giving time for the midi device to be initialised, and this resolves the issue.

this seems to be a bug PD and midi (alsa), perhaps could just be on arm platforms, or even just the version of the alsa library we are using, so I think its unlikely we will see a fix any time soon, but fortunately we can work around it.

note: we don’t know this was introduced in 48, only its not in 46 looking at the change logs, I suspect, it might have actually be introduced in 47.