Re: [PD] Start Pd 0.51-4 without internet connection

[Josh Moore]

On windows he will need to allow pd thru the firewall

On Wed, Jul 14, 2021, 2:04 PM Dan Wilcox  wrote:

> Something is weird with your system. In general, localhost should *always*
> be available.
>
> What happens when you run the following in Terminal with wifi off? Press
> CTRL+C to stop once it's running.
>
> ping localhost
>
> On Jul 6, 2021, at 9:55 AM, pd-list-requ...@lists.iem.at wrote:
>
> Message: 3
> Date: Tue, 6 Jul 2021 09:39:55 +0200
> From: Maurice Moncozet 
> To: pd-list@lists.iem.at
> Subject: [PD] Start Pd 0.51-4 without internet connection
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
> When I have no internet connection I can start Pd 0.52-2 (iMac Mojave) with
> the Terminal by going through Contents/resources/Bin/pd.
> But it does not work with Pd 0.52-3 and Pd 0.52-4.
> This is what the Terminal reports :
>
> Last login: Tue Jul  6 09:30:01 on ttys000
> mauricemoncozet-1:~ moncozetmaurice$
> /Applications/Pd-0.51-4.app/Contents/Resources/bin/pd ; exit;
> localhost not found (inet protocol not installed?)
> nodename nor servname provided, or not known (8)logout
> Saving session...
> ...copying shared history...
> ...saving history...truncating history files...
> ...completed.
>
> [Op?ration termin?e]
>
> What setting should I make?
> Thank you for your response.
>
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "make app" for vanilla?

[Josh Moore]

another thing is i've been playing around with csound and the web and the
way it handles creating guis is just easier. you can get lost for days
finding free javascript buttons and stuff like that.(good example is
https://freefrontend.com/css-buttons/ 167 button designs, lots are 3d it's
crazy... hell you want a javascript keyboard you got that too
https://codepen.io/gabrielcarol/pen/rGeEbY )

i seen chatter about an emscripten compiled pdlib in this list not too long
ago so that's another way to distribute, you can even run this kind of
thing on a github page. pure javascript so...

I think if I ever do anything in a public form like that i will probably
just use the web from now on. performance is fine, don't gotta download
anything to use it. don't need special tools to code for it, just browser
and text editor and ur dsp config. latency is so-so though not unusable
(30-40 ms).

On Thu, Dec 31, 2020 at 1:21 PM Alexandre Torres Porres 
wrote:

> Hi, we all know Pd Extended had that nice feature of sharing your patch as
> an app, could that be available for Vanilla as a plugin? What would it
> take? What other similar solution could we have instead?
>
> Of course we can just share a zipped file with the patch and all external
> dependencies, and then ask people to download Pd vanilla, but the "app"
> idea is still more convenient for complete dummies.
>
> cheers
> happy 2021
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "make app" for vanilla?

[Josh Moore]

not a vanilla solution but i know ofelia allows you to do this though it's
probably not as user friendly and i don't use that feature... supposedly
compiles to ios, windows, macos, linux. the demo examples did compile on my
machine and i checked it out and it's pretty neat but i'm not really
interested in that i just wanted to use lua in my patches
https://github.com/cuinjune/Ofelia

On Thu, Dec 31, 2020 at 1:21 PM Alexandre Torres Porres 
wrote:

> Hi, we all know Pd Extended had that nice feature of sharing your patch as
> an app, could that be available for Vanilla as a plugin? What would it
> take? What other similar solution could we have instead?
>
> Of course we can just share a zipped file with the patch and all external
> dependencies, and then ask people to download Pd vanilla, but the "app"
> idea is still more convenient for complete dummies.
>
> cheers
> happy 2021
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI in vanilla?

[Josh Moore]

I think it comes down to PD's horrible selection of array types. Having
arrays with multi dimensions that can be a choice between int and float
types signed and unsigned without conversion is what you need otherwise you
will run into this wall all over the place and you're looking at a c
compiler or interpreted language external to make what exists in almost
every other language (ie make 16 arrays with 127 dimensions for each note
with byte alignment containing n points or whatever) as three lines of code
doable on a system that has only 2d arrays and float types.

On Mon, Oct 26, 2020, 4:12 AM Christof Ressi  wrote:

> I agree that we really need a way to read/write binary data. I have
> already thought about doing a PR to add such functionality to graphical
> arrays. It would be as simple as adding a flag to the [read( and [write(
> methods.
>
> In theory, it would be possible then to implement a MIDI file
> reader/writer as a Pd abstraction. But to be honest, I think only a
> masochist would do that :-)
>
> On the other hand, mrpeach's [midifile] has always served me well and it's
> one of those things that don't really get obsolete. So I don't think that
> Pd really needs built-in MIDI file support. After all, even a kitchen-sink
> language like Supercollider doesn't come with built-in MIDI file support.
>
> Christof
> On 26.10.2020 11:11, Roman Haefeli wrote:
>
> On Mon, 2020-10-26 at 03:32 -0300, Alexandre Torres Porres wrote:
>
>
> It feels to me Vanilla should be able to read/write MIDI files, but I
> wonder how. Any ideas on how this could work in a "vanilla way"
> (light and simple)?
>
>
> To use Miller's words from another thread, I think reading/writing MIDI
> files would be an application for which the infrastructure is still
> missing: reading from/writing to binary files (unless I missed some
> recent development).
>
> Both would be cool, accessing them from disk directly and load/dump
> them to/from tables.
>
> Roman
>
>
> ___pd-l...@lists.iem.at mailing 
> list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] RPI stereo USB audio was: audio interface with multiple ins on raspberry pi

[Josh Moore]

The Pi 2 and 3's usb were very much hacks due to the limitations of the
Broadcom chip. It's fixed in the Pi4. See here for info:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md





On Wed, Oct 7, 2020 at 5:18 AM Dan Wilcox  wrote:

> To add on to Chris's question with a tangent, have any of you had good
> experience with bog-standard stereo USB Audio interfaces and RPI 3 or 4?
>
> Some years ago now, I tried to use an RPI 2 with my trusty USB 1.1
> standard audio interface (Roland Edirol UA-25) which is full-duplex stereo,
> 2 in / 2 out. I could never get it to work well in full-duplex mode without
> dropouts, even with a low-latency kernel and other real-time tweaks. In the
> end, it seemed the USB driver on the RPI was simply not designed for the
> "isynchronous audio" this requires.
>
> The same device worked well on my original wearable, a Pentium 3 500 MHz
> machine but with a dedicated USB controller chip.
>
> In the end, I decided to move toward iOS for embedded/wearable (hence
> PdParty) and the same device works very well at low-latencies on iPads and
> my (now old) iPhone 5S.
>
> I'd like to still be able to run the setup with alternate systems, so does
> anyone have experience that the USB drivers have been improved? Thanks in
> advance
>
> On Oct 6, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
>
> Date: Tue, 6 Oct 2020 10:48:48 +0800
> From: Chris McCormick 
> To: PD List 
> Subject: [PD] audio interface with multiple ins on raspberry pi
> Message-ID: <5f3198d4-6210-4b41-d3a6-2cccbd3aa...@mccormick.cx>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hey all,
>
> Same question as the previous poster but I was wondering about inputs
> rather than outputs. Ideal solution:
>
>  * USB.
>  * Low cost.
>  * More than 2 channels in.
>  * Headphone sized jacks.
>  * Works with Raspberry Pi.
>
> I've searched but could not find such a beast. Any hints?
>
> Cheers,
>
> Chris.
>
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] audio interface with multiple outs on raspberry pi

[Josh Moore]

I'm getting a brand new rockpro64 but it will be some time before it gets
here as it's coming from China. It's a little bit more than the rpi but not
by much (twice the price is still peanuts compared to the rest of the
single board space compared to features) and it actually has four i2s
connectors (four stereo pairs, making direct connected ADAT possible) plus
a true onboard codec carrying both spdif and analog, pci-e, and
hexacore (a72/53) with quad core mali 860 for 80 bucks for the 4 gig
model... and no weird Broadcom hardware gotchas.

If i can get reliable multi-channel audio with it, i'll ping this thread
again as it might be useful for someone else.

On Fri, Oct 2, 2020 at 2:24 AM Jakob Laue  wrote:

> Dear 0xFFriends,
> I am looking for an usb audio interface that has at least 8 outputs so
> that I can have at least 4 stereo outputs from within pd. The challenge: I
> am on a raspberry pi (2 and 3). Does someone of you know about an audio
> interface that supplies this number of outputs AND works with a raspi?
>
> Or is it possible to buy 4 cheap audio interfaces with 2 outputs each and
> use the simultaneously?
>
> Best, Jakob
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] multichannel vs many stereo writesf objects?

[Josh Moore]

One writesf~ is better.

If you want to extract the wavs to their own track, well they're basically
broadcast wavs. I'm quite fond of BWF.

Just be aware that it's 32 bit unless they've updated it to 64 bit wav and
you'll have a 4 gb size limit which for multichannel wavs uses up rather
quickly.

On Mon, Sep 28, 2020 at 11:00 AM Fede Camara Halac 
wrote:

>
> Hi,
>
> What is more efficient for recording, say, a +15 minute 16 channel
> performance: a single writesf with 16 channels or 8 writesf object with 2
> channels each?
>
> Bonus question: What if I place a stereo writesf inside a patch and run 8
> separate pd~ objects?
>
> The context: recording network performance using Netty McNetface. This is
> why I'm trying to reduce as much processing from the main patch while
> staying within pd-land. (Routing multichannel audio out to another daw
> would be an option that I'm not considering right now)
>
> Thanks!
>
> f
> fdch.github.io
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Advice on distributing pd-based software for apple

[Josh Moore]

Then like I said, you want to play with Apple you must play with their
rules. Pay the hundred bucks and you can go past all those extra steps,
don't and you're stuck doing the work around which will eventually be
blocked regardless. They aren't budging on it. You get to submit apps to
get signed by Apple as such, which is required to get on the app store.
There's just no other way around it.

On Sat, Sep 19, 2020 at 3:37 AM João Pais  wrote:

> that's unfortunately not a practical solution either, to buy more
> hardware. the software already ran on laptops, and several people preferred
> an app (which is an even worse minefield for a developer).
>
> I think no one should buy apple anyway, but many people do, and my problem
> is how to get to them.
>
> On Sat, 19 Sep 2020 at 11:12, Josh Moore  wrote:
>
>> Well what I'm saying is the musicians who don't even know what pd, unix,
>> or a terminal is might be more warm to just buying an instrument that has
>> pd inside of it especially in this era of "anti-DAW" electronic music
>> trends, and music in general where almost any new gear that's had software
>> out in the sort of depths of experimental hell have had gear issues of the
>> same thing and get immediately picked up by big magazines.  You can buy an
>> organelle with pd inside of it today.
>> https://www.engadget.com/2019-11-08-critter-and-guitari-organelle-music-computer-review-jack-of-all-trades.html
>> Nothing really stops you from doing the same thing. It's not my decision
>> to do what Apple has done, That is all on them. I i just don't  believe you
>> should be practically forced to pay a company to distribute a free project
>> on their platform.
>>
>>
>> On Sat, Sep 19, 2020 at 2:04 AM João Pais  wrote:
>>
>>> "my thing" is to make my program available to people who don't know what
>>> pd, unix, or a terminal is and just want to play their instrument. these
>>> people have chosen and paid for their hardware to work with, and all those
>>> arguments are moot for them. I guess I can tell them "more than half of the
>>> world is wrong and I am right, you all should correct yourself and do as I
>>> say", but I think it won't take me far.
>>>
>>> On Sat, 19 Sep 2020 at 10:47, Josh Moore  wrote:
>>>
>>>> Then pay Apple for the privilege of catering to musicians if that's
>>>> your thing more than ethics of a company acting worse than Bill Gates and
>>>> Ballmer era Microsoft combined when it comes to being tone deaf towards the
>>>> developer community and anti-competitive business practices.  There's
>>>> really not much way around this problem, and they aren't going to change
>>>> their mind without a court injunction over their antitrust behavior which
>>>> might be coming sooner rather than later. Even so, you could also build
>>>> upon Raspberry Pis, Belas, and other types of that kind of platform and
>>>> sell pre-configured instruments for musicians as well and target modular,
>>>> and you would make some money from it as well. That ecosystem right now is
>>>> very healthy.
>>>>
>>>> On Sat, Sep 19, 2020 at 1:34 AM João Pais  wrote:
>>>>
>>>>> Unfortunately that's not applicable in my case.  Most musicians use
>>>>> apple,  and telling them all that will be met with a shrug and a "so 
>>>>> what"?
>>>>>
>>>>> Josh Moore  schrieb am Sa., 19. Sep. 2020,
>>>>> 07:57:
>>>>>
>>>>>> Not sure it's even really worth it. Apple is hostile to open source
>>>>>> and multi-platform stuff these days and everyone else who isn't them to 
>>>>>> be
>>>>>> quite honest.
>>>>>>
>>>>>> They want to control graphics (deprecate opengl, don't support
>>>>>> vulkan, force everyone to use their special API completely incompatible
>>>>>> with everything else, boot Epic's engine cuz it doesn't want to pay a
>>>>>> premium conveniently during their push for Arcade and all of this)
>>>>>>
>>>>>> They want to control their processors, lock them down, force you to
>>>>>> pay a hundred bucks a year to access the latest development tools or
>>>>>> distribute applications, and reject anything they don't like or competes
>>>>>> with anything they have unless they make more money from you than they 
>>>>>> make
>>>>>> from their own softwa

Re: [PD] Advice on distributing pd-based software for apple

[Josh Moore]

Well what I'm saying is the musicians who don't even know what pd, unix, or
a terminal is might be more warm to just buying an instrument that has pd
inside of it especially in this era of "anti-DAW" electronic music trends,
and music in general where almost any new gear that's had software out in
the sort of depths of experimental hell have had gear issues of the same
thing and get immediately picked up by big magazines.  You can buy an
organelle with pd inside of it today.
https://www.engadget.com/2019-11-08-critter-and-guitari-organelle-music-computer-review-jack-of-all-trades.html
Nothing really stops you from doing the same thing. It's not my decision to
do what Apple has done, That is all on them. I i just don't  believe you
should be practically forced to pay a company to distribute a free project
on their platform.


On Sat, Sep 19, 2020 at 2:04 AM João Pais  wrote:

> "my thing" is to make my program available to people who don't know what
> pd, unix, or a terminal is and just want to play their instrument. these
> people have chosen and paid for their hardware to work with, and all those
> arguments are moot for them. I guess I can tell them "more than half of the
> world is wrong and I am right, you all should correct yourself and do as I
> say", but I think it won't take me far.
>
> On Sat, 19 Sep 2020 at 10:47, Josh Moore  wrote:
>
>> Then pay Apple for the privilege of catering to musicians if that's your
>> thing more than ethics of a company acting worse than Bill Gates and
>> Ballmer era Microsoft combined when it comes to being tone deaf towards the
>> developer community and anti-competitive business practices.  There's
>> really not much way around this problem, and they aren't going to change
>> their mind without a court injunction over their antitrust behavior which
>> might be coming sooner rather than later. Even so, you could also build
>> upon Raspberry Pis, Belas, and other types of that kind of platform and
>> sell pre-configured instruments for musicians as well and target modular,
>> and you would make some money from it as well. That ecosystem right now is
>> very healthy.
>>
>> On Sat, Sep 19, 2020 at 1:34 AM João Pais  wrote:
>>
>>> Unfortunately that's not applicable in my case.  Most musicians use
>>> apple,  and telling them all that will be met with a shrug and a "so what"?
>>>
>>> Josh Moore  schrieb am Sa., 19. Sep. 2020,
>>> 07:57:
>>>
>>>> Not sure it's even really worth it. Apple is hostile to open source and
>>>> multi-platform stuff these days and everyone else who isn't them to be
>>>> quite honest.
>>>>
>>>> They want to control graphics (deprecate opengl, don't support vulkan,
>>>> force everyone to use their special API completely incompatible with
>>>> everything else, boot Epic's engine cuz it doesn't want to pay a premium
>>>> conveniently during their push for Arcade and all of this)
>>>>
>>>> They want to control their processors, lock them down, force you to pay
>>>> a hundred bucks a year to access the latest development tools or distribute
>>>> applications, and reject anything they don't like or competes with anything
>>>> they have unless they make more money from you than they make from their
>>>> own software.
>>>>
>>>> All anyone needs to do is fork some RTOS *nix microkernel with decent
>>>> support for graphics hardware and nobody has a reason to use that stuff
>>>> anymore unless they want to use Logic. This is basically what Blackmagic
>>>> did for their new hardware, it's all RTLinux as is a lot of the new digital
>>>> consoles. But regardless of my gripes with Apple's crappy antics lately
>>>> these things are really something Miller himself needs to take up with
>>>> Apple as they do offer free app store access to universities and they might
>>>> be interested in embedding Pdlib in logic environment to compete with
>>>> Ableton. We'd have to get externals merged by Miller for this to work out
>>>> though as since the whole Unreal Engine debacle caused Apple to change
>>>> their ToS requiring each piece of code/app has to be ran through
>>>> their approval process or they'll cut you off of xcode/app store/apple id
>>>> with no recourse. But beyond that it's so much cheaper especially for the
>>>> students this software is aimed at primarily to just stick pd on a RT
>>>> patched linux kernel on a 50 dollar ARM SBC and call it good.
>>>>
>>>> On Fri, Sep 18,

Re: [PD] Advice on distributing pd-based software for apple

[Josh Moore]

>
> <https://lists.puredata.info/listinfo/pd-list>
>> And more to this point...
>> https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/
>>
>> This means that once the transition to Apple Silicon takes place, in the
>> future you might not be able to distribute binary form stuff not
>> distributed through the App Store and/or signed by a registered developer
>> eventually. You will be able to compile source code and run your own
>> signatures, but otherwise you're SOL. It's clear from their latest actions
>> that even the "allow" button in the control panel is a stop-gap measure.
>> Better off just distributing the source code with a shell script and having
>> everyone self sign their apps, same amount of terminal commands just a bit
>> of waiting. You could theoretically distribute externals that way too by
>> calling the shell API from pd itself after it's compiled. Heck you could
>> probably do it with deken and tcl alone and not have to worry about
>> packaging multi-os packages they'd just have to wait a little longer than
>> getting a binary. I've had success getting pd to compile in Windows
>> Subsystem for Linux which can run as a terminal right in VS Code it's
>> freaking awesome to be honest and as VS Code also has a OSX counterpart (as
>> with Linux) it's relatively trivial to just modify the environment,
>> generate one big sh file with a case selection for what machine you want to
>> target, and you're done.
>>
>> On Fri, Sep 18, 2020 at 11:00 PM Josh Moore 
>> wrote:
>>
>>> Not sure it's even really worth it. Apple is hostile to open source and
>>> multi-platform stuff these days and everyone else who isn't them to be
>>> quite honest.
>>>
>>> They want to control graphics (deprecate opengl, don't support vulkan,
>>> force everyone to use their special API completely incompatible with
>>> everything else, boot Epic's engine cuz it doesn't want to pay a premium
>>> conveniently during their push for Arcade and all of this)
>>>
>>> They want to control their processors, lock them down, force you to pay
>>> a hundred bucks a year to access the latest development tools or distribute
>>> applications, and reject anything they don't like or competes with anything
>>> they have unless they make more money from you than they make from their
>>> own software.
>>>
>>> All anyone needs to do is fork some RTOS *nix microkernel with decent
>>> support for graphics hardware and nobody has a reason to use that stuff
>>> anymore unless they want to use Logic. This is basically what Blackmagic
>>> did for their new hardware, it's all RTLinux as is a lot of the new digital
>>> consoles. But regardless of my gripes with Apple's crappy antics lately
>>> these things are really something Miller himself needs to take up with
>>> Apple as they do offer free app store access to universities and they might
>>> be interested in embedding Pdlib in logic environment to compete with
>>> Ableton. We'd have to get externals merged by Miller for this to work out
>>> though as since the whole Unreal Engine debacle caused Apple to change
>>> their ToS requiring each piece of code/app has to be ran through
>>> their approval process or they'll cut you off of xcode/app store/apple id
>>> with no recourse. But beyond that it's so much cheaper especially for the
>>> students this software is aimed at primarily to just stick pd on a RT
>>> patched linux kernel on a 50 dollar ARM SBC and call it good.
>>>
>>> On Fri, Sep 18, 2020 at 8:53 AM João Pais  wrote:
>>>
>>>> Hi list,
>>>>
>>>> I'm preparing a package based on Pd work, but I run into annoying
>>>> problems with recent apple OSs, namely notarization and security. Things
>>>> seem to work if the user commits to switching off all security protocols,
>>>> but for people who don't know Pd, they might be squeamish about this.
>>>> Therefore I wanted to ask a couple of questions to someone who might have
>>>> experience in distributing pd-based patches.
>>>>
>>>> For clarity: the package is a max patch (for both runtime and
>>>> standalone versions), with the Pd app and patches included in a supporting
>>>> folder - running with the recent pd~ object. When done properly, the user
>>>> won't even be aware that pd itself is running.
>>>>
>>>> - how can one avoid asking a user to allow safety access to Pd and its
>

Re: [PD] Advice on distributing pd-based software for apple

[Josh Moore]

Not sure it's even really worth it. Apple is hostile to open source and
multi-platform stuff these days and everyone else who isn't them to be
quite honest.

They want to control graphics (deprecate opengl, don't support vulkan,
force everyone to use their special API completely incompatible with
everything else, boot Epic's engine cuz it doesn't want to pay a premium
conveniently during their push for Arcade and all of this)

They want to control their processors, lock them down, force you to pay a
hundred bucks a year to access the latest development tools or distribute
applications, and reject anything they don't like or competes with anything
they have unless they make more money from you than they make from their
own software.

All anyone needs to do is fork some RTOS *nix microkernel with decent
support for graphics hardware and nobody has a reason to use that stuff
anymore unless they want to use Logic. This is basically what Blackmagic
did for their new hardware, it's all RTLinux as is a lot of the new digital
consoles. But regardless of my gripes with Apple's crappy antics lately
these things are really something Miller himself needs to take up with
Apple as they do offer free app store access to universities and they might
be interested in embedding Pdlib in logic environment to compete with
Ableton. We'd have to get externals merged by Miller for this to work out
though as since the whole Unreal Engine debacle caused Apple to change
their ToS requiring each piece of code/app has to be ran through
their approval process or they'll cut you off of xcode/app store/apple id
with no recourse. But beyond that it's so much cheaper especially for the
students this software is aimed at primarily to just stick pd on a RT
patched linux kernel on a 50 dollar ARM SBC and call it good.

On Fri, Sep 18, 2020 at 8:53 AM João Pais  wrote:

> Hi list,
>
> I'm preparing a package based on Pd work, but I run into annoying problems
> with recent apple OSs, namely notarization and security. Things seem to
> work if the user commits to switching off all security protocols, but for
> people who don't know Pd, they might be squeamish about this. Therefore I
> wanted to ask a couple of questions to someone who might have experience in
> distributing pd-based patches.
>
> For clarity: the package is a max patch (for both runtime and standalone
> versions), with the Pd app and patches included in a supporting folder -
> running with the recent pd~ object. When done properly, the user won't even
> be aware that pd itself is running.
>
> - how can one avoid asking a user to allow safety access to Pd and its
> externals? And while at that, to the max standalone as well?
> - I'm myself a windows user, and don't have a mac - I can only get the
> standalone compiled when a friend grants me access to his computer. Which
> system do you advise to prepare a package? It works fine in 10.13, from
> 10.15 seems to be problematic.
> - I had a look at codesigning a package, but it seems that it's necessary
> to sign up as an apple developer and pay 100us a year, which I'm not
> willing to do. The package won't be going to any app store, it's just to
> distribute as a zip file for computers. Any way to circumvent this?
>
> Best,
>
> jmmmp
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New "fast-forward" message

[Josh Moore]

I wonder if having an embedded version of pdlib built to do that would work
as you'd separate that from the scheduler, it would basically just run it's
own scheduler but you wouldn't have to manage threads (and i think it took
Csound quite a long time for them to get realtime with multiple threads
working well).

On Mon, Aug 17, 2020 at 10:53 AM Josh Moore  wrote:

> Yeah I think that would be a limitation that's unavoidable, because you're
> running at system clock rates vs audio clock rates. You'd have to spawn a
> new thread.
>
> On Mon, Aug 17, 2020 at 10:40 AM Christof Ressi 
> wrote:
>
>> Try attached patch. Note that this works fine with pure DSP objects, but
>> it gives unexpected results once you add clocks (e.g. [metro], [del], etc.).
>>
>> Sending a "bang" to [switch~] only advances DSP computation for the given
>> canvas (and all its subcanvases), but it doesn't advance the message
>> scheduler (which is global).
>>
>> With this method, you can basically amortized DSP computations over a
>> given period of time.
>>
>> Christof
>> On 17.08.2020 19:27, Alexandre Torres Porres wrote:
>>
>>
>>
>> Em seg., 17 de ago. de 2020 às 13:20, Christof Ressi <
>> i...@christofressi.com> escreveu:
>>
>>> If your audio computation is pure DSP (i.e. no messages), you can
>>> "render" it by repeatedly banging the [switch~] object at any rate you
>>> like. Global DSP still has to be on, but the canvas would be switched off.
>>>
>>
>> hmm, please elaborate;
>> thanks
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New "fast-forward" message

[Josh Moore]

Yeah I think that would be a limitation that's unavoidable, because you're
running at system clock rates vs audio clock rates. You'd have to spawn a
new thread.

On Mon, Aug 17, 2020 at 10:40 AM Christof Ressi 
wrote:

> Try attached patch. Note that this works fine with pure DSP objects, but
> it gives unexpected results once you add clocks (e.g. [metro], [del], etc.).
>
> Sending a "bang" to [switch~] only advances DSP computation for the given
> canvas (and all its subcanvases), but it doesn't advance the message
> scheduler (which is global).
>
> With this method, you can basically amortized DSP computations over a
> given period of time.
>
> Christof
> On 17.08.2020 19:27, Alexandre Torres Porres wrote:
>
>
>
> Em seg., 17 de ago. de 2020 às 13:20, Christof Ressi <
> i...@christofressi.com> escreveu:
>
>> If your audio computation is pure DSP (i.e. no messages), you can
>> "render" it by repeatedly banging the [switch~] object at any rate you
>> like. Global DSP still has to be on, but the canvas would be switched off.
>>
>
> hmm, please elaborate;
> thanks
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New "fast-forward" message

[Josh Moore]

this sounds interesting. i've also successfully written to an array. i've
always liked this idea, it makes no sense to compute something over and
over again if you already know what's going to be computed. playing back a
bit stream from RAM is always going to be faster.

i can have some fun with this and i know exactly the application to use it
for as i've (ab)used this sort of "render to sample" feature in Renoise.

On Mon, Aug 17, 2020 at 12:48 AM Alexandre Torres Porres 
wrote:

> I'm having so much fun, thanks!
>
> working on a "batch record" abstraction now :)
>
> I'm only now frustrated I can't batch record myself playing live, for
> like, 5 minutes... maybe Miller will figure out a way of doing so in 0.52
> :)
>
> Em dom., 16 de ago. de 2020 às 21:54, Christof Ressi <
> i...@christofressi.com> escreveu:
>
>> Hey,
>>
>> but I still needed an example to see how to make this happen :)
>>
>> Attached you find a simple example for recording N ms of sound to disk.
>>
>> that's used n the help file of [samplerate~] but I agree it should also
>> be included in this new documentaton section. Anyway, what else would you
>> use it for?
>>
>> It's useful for preventing "angry vline~s": if you accidentally keep
>> sending messaes to a [vline~] while DSP is off, it will eventually bring Pd
>> to its knees. The solution is to use a [spigot] which is opened on
>> "pd-dsp-started" and closed on "pd-dsp-stopped".
>>
>> Actually, the issue should be mentioned in vline~-help.pd, together with
>> the possible solution.
>>
>> Christof
>> On 17.08.2020 02:25, Alexandre Torres Porres wrote:
>>
>> On 16.08.2020 05:52, Miller Puckette via Pd-list wrote:
>>> > An artificial example (for simplicity) - I want to apply a Pd effect
>>> to a
>>> > soundfile and write the result out to another file, without having to
>>> wait
>>> > for the length of the file to get the result.  This could be done from
>>> the
>>> > command line using a batch command, but while you're developing the
>>> patch to
>>> > do it it's much easier to be able to set the process off with a button
>>> from
>>> > inside Pd.
>>>
>>
>> Great, kind of what I was expecting, but I still needed an example to see
>> how to make this happen :)
>>
>> Em dom., 16 de ago. de 2020 às 08:16, Christof Ressi <
>> i...@christofressi.com> escreveu:
>>
>>> My use case was that I had a patch which either produced some generative
>>> music or processed some soundfile and I wanted to record N seconds as
>>> fast as possible. It's basically like the render function in a DAW
>>> (usually you don't have to start the DAW from the command line to render
>>> your project :-).
>>>
>>
>> I also thought about that and I'm really excited to test both things.
>> Hopefully I can have an example of this in my tutorial rght now and release
>> an update. But my attempts here failed and froze Pd :)
>>
>> Have you already messed with it, Christof?
>>
>>
>>> But I agree that this needs to documented. Generally, there should be a
>>> section to document all (public) Pd messages, like [pd dsp(, [pd quit(,
>>> etc. (What can be considered "public"?)
>>>
>>
>> I opened an issue for that (
>> https://github.com/pure-data/pure-data/issues/1125 ) and can take care
>> of it as I'm usually handling documentation issues.
>>
>>
>>> Also [r pd-dsp-started] and [r pd-dsp-stopped], which most people don't
>>> know about, I guess.
>>>
>>
>> that's used n the help file of [samplerate~] but I agree it should also
>> be included in this new documentaton section. Anyway, what else would you
>> use it for?
>>
>> Porres
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list