[PD] Pd download pages are down

Hi, Just wanted to report that at the moment there is no way to download Pd from: * http://puredata.info/downloads/pure-data * http://msp.ucsd.edu/software.html because these seem to be both "broken". Cheers, Mario -- musician, QA engineer, mental health first aider MHFA England

[PD] announce: deken.puredata.info

"whether deken find objects, solely depends on whether the uploader decided to upload an objects-list file (*.dek.txt)." I think that answers my question :) Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->

Re: [PD] announce: deken.puredata.info

That is just amazing! Thanks for this Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Re: [PD] announce: deken.puredata.info

:46, Mario Buoninfante wrote: > That is just amazing! > Thanks for this > > Cheers, > Mario > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] r_cycle | Pd library for creative coding with Launchpads

Hi, I'm really glad to announce the release of r_cycle, a project I've been working on recently, initially presented at the end of last year in London in the form of a workshop. r_cycle is a Pd (Vanilla) library developed to work with Launchpads (old and new) that can also be used for other

Re: [PD] Pd Test Suite

Hi Fred, Thanks for sharing, I'll have a look at it. Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

[PD] Pd Test Suite

Hi all, Like I mentioned a couple of days ago, I'm currently working on a simple test suite for Pd, hoping this could be useful when working on new features/releases. The idea is to have a high level test suite that doesn't test the source code but instead runs Pd, then launches the tests and

Re: [PD] Pass arg to Pd via terminal

Yap, absolutely it does make sense, and I wouldn't skip the extension unless it was clear that was an accepted behavior. I guess with mandatory what I mean is: Does Pd open a patch that doesn't have the .pd extension? Then whether or not this is good practice it's a different story. But yes, I do

[PD] Pass arg to Pd via terminal

actually it seems .pd is not mandatory, right? Anyway I like this :) pd -open "mypatch1.pd: 1 2 3" -open "mypatch2: foo bar" ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

[PD] Pass arg to Pd via terminal

Good point about colons and semicolons not being 100% safe. Only thing I would say is that they will only be there after ".pd" and this should make it safer (easier to parse!?!?!). +1 for pd -open "mypatch1.pd: 1 2 3" -open "mypatch2: foo bar" ___

[PD] Pass arg to Pd via terminal

ChucK uses an interesting syntax to pass arguments to programs that we could consider borrowing: > chuck myprog.ck:23:anotherArg myprog2.ck:42 that in our case would be: > pd mypatch.pd:23:anotherArg mypatch2.pd:42 ___ Pd-list@lists.iem.at mailing list

[PD] Pass arg to Pd via terminal - Test Suite

Yap, in the end I put a [receive] in the patch as a workaround. I'll open a ticket on github then, I suppose this could be useful. Just to give you a bit more context here, the reason why I'm asking for this is because I'm prototyping a test suite for Pd - ie for "continuous integration' or

[PD] Pass arg to Pd via terminal

Hi Christof, Just read your email, thanks guys for your help! Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

[PD] Pass arg to Pd via terminal

Hi Jack, Thanks for your help. That's great but is not exactly what I'm looking for. In my previous email I missed an important bit, what I'd like to do is pass an arg to a specific patch. Something like > pd mypatch.pd 23 and then in "mypatch" I have [$1] that is now 23. Cheers, Mario

[PD] Pass arg to Pd via terminal

Hi, Is it possible to pass arguments to Pd via terminal? I know we don't have [stdin], but I was wondering if there is any other way. Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->

Re: [PD] MIDI 2.0

t; been done by modifying MIDI handling in s_midi.c. > > On Apr 6, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at wrote: > > Message: 1 > Date: Mon, 6 Apr 2020 10:51:26 +0100 > From: Mario Buoninfante > To: pd-list > Subject: [PD] MIDI 2.0 > Message-ID: > > Con

[PD] MIDI 2.0

Hi all, Is there any plan to support MIDI 2.0? I know this is more of a question about PortMidi, but I was wondering if anybody knows anything about it. Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->

[PD] start and end point (WAV files)

Hi, >From what I read this may be not needed, but for those interested here you can find the wav specs http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and

Re: [PD] next PdCon?

I would love it! Looking forward to hearing a bit more ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

[PD] r_cycle | creative coding with Pure Data and Launchpad

Hi Max, Patrick Max, sorry I didn't know PD-Annouce was linked in some way to the PD list. I'll keep in mind for the next time. Patrick, there will be a repo available soon. I'll keep you posted. Cheers, Mario ___ Pd-list@lists.iem.at mailing list

[PD] [PD-announce] r_cycle | creative coding with Pure Data and Launchpad

Hi, October 29th I'm giving a talk about r_cycle, an open source library/middleware for creative coding with Launchpad, at the Novation pop-up shop in Shoreditch, London. About the library/middleware: r_cycle allows to fully control Launchpad from Pd (bi-directional communication), giving the

[PD] (maybe) issue with abstraction's args

Hi, I'm not sure this is a misbehavior, but there's something I don't quite understand. I have an abstraction that uses a send that looks like [s $1_abstr]. This abstraction is then part of a MAIN patch that has let's say [r 0_abstr]. If in the MAIN patch I create [MY_ABSTR 0], everything

[PD] Pd + Launchpad

Hi, is there anyone who owns a Novation Launchpad Pro and wants to be a beta tester for a new open source project that involves Pd+Launchpad? Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->

Re: [PD] Delay (msec) option in audio properties

> > cheers > Miller > > On Tue, May 14, 2019 at 07:22:55AM +0100, Mario Buoninfante wrote: > > Hi, > > > > Can anyone explain me what's the actual effect of 'Delay (msec)' parameter > > you can find in the audio properties dialog? > > > > C

[PD] Delay (msec) option in audio properties

Hi, Can anyone explain me what's the actual effect of 'Delay (msec)' parameter you can find in the audio properties dialog? Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->

[PD] specify send and return params of GUI objects at their creation

Hi Iohannes, Thanks for that ;) Cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

[PD] specify send and return params of GUI objects at their creation

Hi, Is it possible to create an [hslider] (or other vanilla GUI objects) and specify its send and return params at its creation? ie. [hsl vol_send vol_recv] would generate a slider with send = 'vol_send' and receive = 'vol_recv' Cheers, Mario ___

Re: [PD] SysEx In issue

d midi sysex data and see if PD gets stuck > as well when receiving that. > > Is it new Hardware with usb-midi? (you wrote something about usb earlier) > > > On Mon, Feb 11, 2019, 19:50 Mario Buoninfante wrote: > >> Hi Lucas, >> >> Nope, I'm receiving MIDI f

Re: [PD] SysEx In issue

I got a repro. Here's a video that shows it (pass: sysexissue): https://vimeo.com/316624285 I'll open an issue on github with the patches I used. Cheers, Mario On Mon, 11 Feb 2019 at 19:17, Mario Buoninfante wrote: > Hi Lucas, > > I tried your patch on a MacBook Pro 2.7 GHz Intel Core

Re: [PD] SysEx In issue

Hi Lucas, I tried your patch on a MacBook Pro 2.7 GHz Intel Core i5 16 GB of ram and I can easily send SysEx from your patch faster then 3 ms (1 ms is more than fine and I'm sure we can go even faster). I'm using a virtual MIDI port by the way. In fact the point is, if we're talking about MIDI

Re: [PD] SysEx In issue

saje telepatico asistido por maquinas. > > On 2/11/2019 9:50 AM, Mario Buoninfante wrote: > > No that's not the case. In my video I'm using MidiMonitor at the same > time,and that works fine also when Pd gets stuck. > Also because USB Midi bandwidth is pretty big. > > Cheers, >

Re: [PD] SysEx In issue

? > > > Mensaje telepatico asistido por maquinas. > > On 2/11/2019 9:07 AM, Mario Buoninfante wrote: >> >> I found a clunky workaround I only tested on MacOS Sierra for now. >> I'm automatically setting the MIDI in every 200 ms, using a metro that sends >&g

[PD] SysEx In issue

I found a clunky workaround I only tested on MacOS Sierra for now. I'm automatically setting the MIDI in every 200 ms, using a metro that sends [midi-dialog 2 0 0 0 0 0 0 0 0 2 1 0 0 0 0 0 0 0 4 4(to[s pd] It seems to work, but of course I suspect messages are getting lost. Cheers, Mario

[PD] SysEx In issue

Hi, Not too long ago I wrote here reporting an issue with receiving SysEx messages. When Pd receives a big quantity of SysEx, the MIDI IN port 'gets stuck' and then you need to go to 'Media->MIDI settings...' and re-select the port, otherwise no MIDI messages will be received anymore. Here's a

[PD] Advantages of using [timer] over [realtime]

Hi, What would be the pros and cons in using [timer] instead of [realtime]. I know the latter asks the OS for time, while [timer] deals with logical time. If I got it right, logical time is tied to the sample rate (and block size), so it's basically the 'Pd time'. Another question would also be,

Re: [PD] [text] issue reading SysEx files

a to make an addition to soundfiler > to read binary chanracters into an array. > > cheers > Miller > > On Fri, Jan 18, 2019 at 04:39:04PM +, Mario Buoninfante wrote: > > Hi, > > > > I've been trying to read SysEx files using [text], and I noticed

[PD] [text] issue reading SysEx files

Hi, I've been trying to read SysEx files using [text], and I noticed that the loaded file end up being corrupted in a way with bits and bops missing. Also trying to manually copy and paste part of the file (from Atom text editor) I'm not able to copy the entire file, there's always something

[PD] open [openpanel] window in the patch folder

double checked on Linux (Ubuntu Studio 16.04 64bit) as well and [symbol ./( works, but opens the directory from where Pd has been launched. For example if the patch is in "/MyFolder/PdPatch", and you launch the patch with Pd closed, then [openpanel] will open there when using [symbol ./( In

[PD] open [openpanel] window in the patch folder

Double checked on Win10 and sending a bang to [openpanel] opens the /Documents/Pd path, while [symbol ./( opens the C:/Users/UserName path. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->

[PD] open [openpanel] window in the patch folder

Hi, Would it be possible to use something like the following [symbol ./( | | [openfolder] to open the dialog window in the current patch folder? This syntax works when you save or load files (ie with [textfile]), but doesn't seem to work with [openpanel] and [savepanel]. Cheers, Mario

Re: [PD] triggering [print~] faster than every 64 samples

he largest blocksize within the list of parent canvasses. [block~ 1] on a root canvas is just the simple case where the parent blocksize equals the schedular tick size of 64 samples. Christof Gesendet: Samstag, 28. Juli 2018 um 11:50 Uhr Von: "mario buoninfante" An: "Christof Res

[PD] triggering [print~] faster than every 64 samples

Hi, I'm trying to trigger [print~] every sample. in the same patch I'm using [block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger [print~]. but I noticed that [print~] is yes printing 1 sample at time (in accord with the block size) but only every 64 samples. so it

Re: [PD] Order of operation/connection issue with send and return

es’ point was that even if there is a ‘rule’, you should not depend > on it, and it may change in the future, so basically there is no rule. > Don’t depend on that always working. > > There is no point in trying to understand how it works. Just assume it’s > random. > > > On Tue

Re: [PD] Order of operation/connection issue with send and return

Hi I0hannes, thanks for your reply. you're definitely right, in fact that's how I wrote my patch, I probably kept my question to vague. it's not a problem, I can see several workarounds for that, so it's fine, it's more about better understanding what's going on under the hood. I always use

[PD] Order of operation/connection issue with send and return

Hi, I just noticed that using [send] and [return] the "order of connection" seems to work the other way around. basically if I have a numbox connected to a [send FOO] and then I create 2 [return FOO], the last one I created will receive the message first. this seems to be different from

Re: [PD] MIDI timing FIFO overflowed receiving sysex (pt.2)

yte values for the message? On Jun 16, 2018, at 9:02 AM, pd-list-requ...@lists.iem.at <mailto:pd-list-requ...@lists.iem.at> wrote: From: Mario Buoninfante <mailto:mario.buoninfa...@gmail.com>> To: pd-list mailto:pd-list@lists.iem.at>> Subject: [PD] MIDI timing FIFO overflowed re

[PD] MIDI timing FIFO overflowed receiving sysex (pt.2)

Hi, few months ago I was writing about some issues sending big sysex to Pd. Miller suggested the following *If you don't mind recompiling Pd, you can control the MIDI queue size *>* by editing this line in s_midi.c: *> >* #define MIDIQSIZE 1024 *> >* I think it has to be a power of 2. You could

[PD] add inlets to [ctlin]

Hi I0hannes, I totally agree with you about "premature optimization", but I'm pretty sure as well you agree we're not talking about GOTO statements here :D cheers, Mario ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management

[PD] sparse considerations about jit_expr (was: jit_expr 0.1: Just in time expr/expr~/fexpr~)

Hi Marco, as I said before I really like the idea of introducing a just in time compiler, and I like the ideas you presented here. the only thing I'd say is that I'd avoid introducing in Pd a pseudocode (max/gen~ style). in my opinion using (if possible) an existing scripting language (Lua,

[PD] add inlets to [ctlin]

Hi I0hannes, I'm with you, we are not talking about the most important improvement ever, but honestly still it is an improvement, and I can't see why don't do it :D I know that Pd could perfectly deal with tons of MIDI messages at time, but it's not only matter of dealing with them, but

[PD] add inlets to [ctlin]

Hi Roman, you're absolutely right, in fact that's the way I'm doing. but I suppose that having the possibility to directly set the object would allow to have better performances. Imagine a situation where you have 10 [ctlin] objects in a patch and then you implement the kind of filter

[PD] add inlets to [ctlin]

Hi all, is there any particular reason why on [ctlin] there are no inlets that allow to change MIDI channel and control number on the fly? do you guys think it would be useful to have it? cheers, Mario ___ Pd-list@lists.iem.at mailing list

Re: [PD] [PD-announce] jit_expr 0.1: Just in time compiled, expr/expr~/fexpr~

, Mar 18, 2018 at 10:03 AM, mario buoninfante <mario.buoninfa...@gmail.com <mailto:mario.buoninfa...@gmail.com>> wrote: yap, it looks there are some issue loading the objects. if you go to Browser list and then launch jit_expr help, then you'd be able to load the object.

Re: [PD] [PD-announce] jit_expr 0.1: Just in time compiled expr/expr~/fexpr~

On Sun, Mar 18, 2018 at 9:46 AM, mario buoninfante <mario.buoninfa...@gmail.com <mailto:mario.buoninfa...@gmail.com>> wrote: Hi, this is ground breaking, absolutely amazing. correct me if I'm wrong, but that means with this tool we now have something like gen~ in Max

[PD] [PD-announce] jit_expr 0.1: Just in time compiled, expr/expr~/fexpr~

yap, it looks there are some issue loading the objects. if you go to Browser list and then launch jit_expr help, then you'd be able to load the object. I also tried creating [jit_expr/jit_expr] that returns an error: jit/expr,expr~,fexpr~ version 0.1 maximum object loading depth 1000 reached

[PD] [PD-announce] jit_expr 0.1: Just in time compiled expr/expr~/fexpr~

Hi, this is ground breaking, absolutely amazing. correct me if I'm wrong, but that means with this tool we now have something like gen~ in Max (btw, I know there's Faust that works with Pd). anyway, super cool, I'll give it a try asap. cheers, Mario

Re: [PD] sysex messages

messages and running status messages. On Mar 15, 2018, at 12:00 AM, mario buoninfante <mario.buoninfa...@gmail.com <mailto:mario.buoninfa...@gmail.com>> wrote: it looks like your guess definitely worked :D thanks, Mario On 14/03/18 22:32, Dan Wilcox wrote: I essentially overhau

Re: [PD] sysex messages

t on Linux. Relevant info is here: https://github.com/pure-data/pure-data/pull/214 On Mar 14, 2018, at 11:21 PM, pd-list-requ...@lists.iem.at <mailto:pd-list-requ...@lists.iem.at> wrote: From: Miller Puckette <m...@ucsd.edu <mailto:m...@ucsd.edu>> To: mario buoninfante

Re: [PD] sysex messages

it looks like we're in the clear after all... cheers Miller On Wed, Mar 14, 2018 at 10:06:10PM +, mario buoninfante wrote: Hi Simon, yes the message is received and understood by other devices, so at the end of the day it's not a problem, mine is more curiosity :D btw I've got a little update

Re: [PD] sysex messages

it is perfectly valid to send one byte at a time at least over din midi. in fact i am doing that with arduinos all the time. (usb midi is a different beast) do the “special” midiout noteon and noteoff messages work when a synthmodule or similar is connected? On 14 Mar 2018, at 21:28, mario buoninfante

Re: [PD] sysex messages

usb midi is a different beast) do the “special” midiout noteon and noteoff messages work when a synthmodule or similar is connected? On 14 Mar 2018, at 21:28, mario buoninfante <mario.buoninfa...@gmail.com <mailto:mario.buoninfa...@gmail.com>> wrote: Hi Miller, yap I'm using AL

Re: [PD] sysex messages

00AM +0000, mario buoninfante wrote: Hi, I ran few more tests on Linux trying to understand what's going on with [midiout] and sysex messages. I discovered that it's not just about sysex. I'm monitoring MIDI from Pd with /KMidimon /and /GMIDImonitor/, and I noticed that also sending Note O

[PD] sysex messages

Hi, I ran few more tests on Linux trying to understand what's going on with [midiout] and sysex messages. I discovered that it's not just about sysex. I'm monitoring MIDI from Pd with /KMidimon /and /GMIDImonitor/, and I noticed that also sending Note On messages with [midiout] seems to be

[PD] Pd FLOSS manual update

Hi everyone, I recently had a look at the Pd FLOSS manual (Pd FLOSS ) and seems a bit out of date. so I was wondering if there's anyone interested in updating and

Re: [PD] sysex messages

], and let Pd deal with parsing, would be a faster process. cheers, Mario 2018-02-22 22:40 GMT+00:00 mario buoninfante <mario.buoninfa...@gmail.com>: > yap I'm sending sysex from Circuit. I'm using Components a Novation > website that allows you to store patches and session from Circuit. a

Re: [PD] sysex messages

not sure. Are you sending SYSEX from your Circuit as well? On Thu, Feb 22, 2018 at 2:31 PM, mario buoninfante <mario.buoninfa...@gmail.com <mailto:mario.buoninfa...@gmail.com>> wrote: yap, this makes sense. I imagined Gmidimonitor does that. but why is not parsing

Re: [PD] sysex messages

] to get the raw sysex messages from your Novation circuit, pass them straight to [midiout] and then have a look at Gmidimonitor. Gesendet: Donnerstag, 22. Februar 2018 um 23:31 Uhr Von: "mario buoninfante" <mario.buoninfa...@gmail.com> An: "Christof Ressi" <christof

Re: [PD] sysex messages

] to get the raw sysex messages from your Novation circuit, pass them straight to [midiout] and then have a look at Gmidimonitor. Gesendet: Donnerstag, 22. Februar 2018 um 23:31 Uhr Von: "mario buoninfante" <mario.buoninfa...@gmail.com> An: "Christof Ressi" <christof

Re: [PD] sysex messages

the message. Gmidimonitor parses the byte stream so it can tell you which messages it gets. [midiout] is only responsible for sending raw *bytes* to a MIDI device. it's your job to assemble your MIDI *messages*. Gesendet: Donnerstag, 22. Februar 2018 um 23:05 Uhr Von: "mario buoninfante" <m

Re: [PD] sysex messages

: "mario buoninfante" <mario.buoninfa...@gmail.com> An: Alex <x37v.a...@gmail.com> Cc: pd-list@lists.iem.at Betreff: Re: [PD] sysex messages yap, I know that at the end of the day MIDI is dealing with 1 byte at time. I was wondering why there's a difference between 2 d

Re: [PD] sysex messages

and maybe the Circuit is using that style while Pd doesn't so the interface just sees the messages as bytes instead of grouping it. On Thu, Feb 22, 2018 at 2:05 PM, mario buoninfante <mario.buoninfa...@gmail.com> wrote: yap, I know that at the end of the day MIDI is dealing with 1 byte at t

Re: [PD] sysex messages

of individual bits on the hardware line.. PD's object let you do bytes at a time instead of individual bits :) On Thu, Feb 22, 2018 at 1:47 PM, mario buoninfante <mario.buoninfa...@gmail.com <mailto:mario.buoninfa...@gmail.com>> wrote: Hi Alex, thanks for your reply. I thi

Re: [PD] sysex messages

it in the sysex start and end and output it as individual bytes: https://github.com/x37v/pure_data midi is a byte oriented protocol.. On Thu, Feb 22, 2018 at 1:24 PM, mario buoninfante <mario.buoninfa...@gmail.com <mailto:mario.buoninfa...@gmail.com>> wrote: Hi, do you guys kno

[PD] sysex messages

Hi, do you guys know if there's a way to send a list of sysex messages (or 1 complete message, let's say 8 bytes long) rather then 1 byte per time? if not, do you know if there's a particular reason why it's not possible? cheers, Mario ___

[PD] Issue with MIDI "active sensing" message

Hi All, I noticed that Pd doesn't receive the real time message 254 (0xFE). it's able to generate it, but will ignore it as input. I tried with [midirealtimein] and [midiin]. I'm sure my midi device is generating and receiving this message and Pd is ignoring it. I'm trying sending out the

[PD] Midi Real Time Active Sensing Message Ignored

Hi All, I noticed that Pd doesn't receive the real time message 254 (0xFE). it's able to generate it, but will ignore it as input. I tried with [midirealtimein] and [midiin]. I'm sure my midi device is generating and receiving this message and Pd is ignoring it. I'm trying sending out the message

Re: [PD] MIDI timing FIFO overflowed receiving sysex

un 24, 2017 at 10:25:41AM +0100, mario buoninfante wrote: Hi All, I'm trying to record a bunch of sysex received from and external machine (sequencer/synthesizer). I tried using both [midiin] and [sysexin], and I've always got the same result: "MIDI timing FIFO overflowed" printed on

[PD] MIDI timing FIFO overflowed receiving sysex

Hi All, I'm trying to record a bunch of sysex received from and external machine (sequencer/synthesizer). I tried using both [midiin] and [sysexin], and I've always got the same result: "MIDI timing FIFO overflowed" printed on the console, and a lot of data missing (I'm sure about that,

Re: [PD] refresh MIDI device list on run

Behalf Of Ingo Sent: Sunday, April 09, 2017 10:53 AM To: 'Christof Ressi'; 'mario buoninfante' Cc: pd-list@lists.iem.at Subject: Re: [PD] refresh MIDI device list on run You need to refresh the midi dialog by banging this: [; pd midi-dialog 1 2 3 4 1 2 3 4 4 4( first 4 = input device numbering