from:"Mario Buoninfante"

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 agree that unless this is the case by design (ie no need to
use .pd), one shouldn't do that.
___
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

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-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[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
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-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 simply for testing new features.
I wanted to contribute a bit more to the cause and since this seems to be
something we're missing atm, I thought I could spend some time on this.
It would be great to have some scripts in place that allow us to check new
and old features, to make sure things work fine on different OSs and
machines and that we haven't broken anything while working on a new feature.
As a starting point we could have Pd users running the suite on their
machine and share the logs/results.
I'm prototyping something simple in Lua simple, that shouldn't require too
much effort in terms of maintenance.

I'll open a ticket on github and share more details there.

Please, let me know if you have any thoughts/suggestions/questions.

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 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-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,

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 -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI 2.0

2020-04-06 Thread Mario Buoninfante

Hi Dan,

Thanks for getting back to me.
Yap, I had a look at the protocol and is like you said about
retro-compatibility.
I'm glad to hear that probably can be dealt with making some changes in
s_midi.c, work that of course I know still takes some efforts.
My question though, was more related to the new msg introduced by MIDI 2.0,
with a different structure and resolution.
But I suspect what you said is valid for that as well, right?

Cheers,
Mario


On Mon, 6 Apr 2020 at 14:23, Dan Wilcox  wrote:

> Actually, form what I've read, I don't think MIDI 2 requires any (or very
> many) changes to Portmidi as Portmidi wraps the various OS-level MIDI APIs
> and gives you raw bytes. The actual MIDI protocol interpretation is handled
> in the Pd core.
>
> MIDI 2 is basically an extension of the MIDI 1 protocol and MIDI 2
> messages can contained embedded MIDI 1 messages. There is an additional
> query communication where a device can ask about the capabilities of
> another device. Overall, it seems to be designed to work seamlessly with
> older MIDI 1 devices/software.
>
> Short answer is: I don't think anyone is doing this, but it can probably
> 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:
> 
> Content-Type: text/plain; charset="utf-8"
>
> 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
>
>
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] MIDI 2.0

2020-04-06 Thread Mario Buoninfante

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 -> 
https://lists.puredata.info/listinfo/pd-list

[PD] start and end point (WAV files)

2020-02-12 Thread Mario Buoninfante

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 account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] next PdCon?

2020-01-08 Thread Mario Buoninfante

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

2019-10-28 Thread Mario Buoninfante

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
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2019-10-27 Thread Mario Buoninfante

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 user the possibility to interact with the
device, to create custom UIs in real-time, on-the-fly, simply creating
specific objects (part of the library) in Pd.
It has different 'widgets' and audio/MIDI/utilities objects, all written in
Pd Vanilla, thus doesn't use any external.
For example creating the [KEYBOARD] object in your patch, would generate a
'chromatic keyboard' on the LP (1 octave/12 notes keyboard represented on
the pads).
This would be interactive (ie you press a pad part of the keyboard UI on
the Launchpad and the object in the patch returns one or more values) and
can be deleted simply deleting the [KEYBOARD] object in Pd.
It is possible to use multiple widgets at the same time (you can fill the
Launchpad layout), and also to call multiple scenes.

If you're in London on Tue and you wanna know more, here's more details
about the event:
https://www.eventbrite.co.uk/e/novation-london-learn-hackspace-r-cycle-creative-coding-w-pure-data-registration-74965715473?fbclid=IwAR03--U2-v80-XZkvEQGBLgRwe_0d7D1z4TGdR8lIIBmnOXAoP8GgC8jG1Q

Cheers,
Mario
___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2019-08-03 Thread mario buoninfante


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 works, instead if 
I don't pass any argument to the abstraction (that would then look like 
[MY_ABSTR]), my send and return don't talk to each other anymore.


But still, if I print [$1] in my abstraction (to which I didn't pass any 
argument), this would be 0.


Thus, my question is, if $1 is 0, why [s $1_abstr] and [r 0_abstr] 
aren't linked?



Cheers,

Mario


--
Electronic Musician, Creative Coder, QA Engineer
https://vimeo.com/creativecodingsalerno
http://mbuoninfante.tumblr.com/
https://github.com/mariobuoninfante
https://bitbucket.org/mariobuoninfante/




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Pd + Launchpad

2019-07-25 Thread Mario Buoninfante

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 -> 
https://lists.puredata.info/listinfo/pd-list

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

2019-05-15 Thread Mario Buoninfante

Hi Miller,

Thanks a lot for the explanation.

Cheers,
Mario

-- Electronic Musician, Creative Coder, QA Engineer 
https://vimeo.com/creativecodingsalerno http://mbuoninfante.tumblr.com 
https://github.com/mariobuoninfante https://bitbucket.org/mariobuoninfante


On 14 May 2019 5:39 pm, Miller Puckette  wrote:
>
> Rough explanation:  Pd sets up two FIFOs, one for audio input and one for 
> output, and "delay" sets the length of those FIFOs.  I/O is managed so that 
> (in theory at least) the sum of the number of sample frames in the input 
> and the output FIFOs add up to the "delay", plus or minus one 64-saple block. 
>
> So theoretically at least, the total delay from audio input to output should 
> be the sum of three things: this number, the OS's internal audio latency 
> (which depends on all sorts of factors) and the A/D/A devices. 
>
> 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? 
> > 
> > Cheers, 
> > Mario 
>
> > ___ 
> > 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] Delay (msec) option in audio properties

2019-05-14 Thread Mario Buoninfante

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 -> 
https://lists.puredata.info/listinfo/pd-list

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

2019-03-20 Thread Mario Buoninfante

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

2019-03-20 Thread Mario Buoninfante

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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] SysEx In issue

Hi Simon,

all the info and the patches I used can be found here:
https://github.com/pure-data/pure-data/issues/554

Cheers,
Mario

On Mon, 11 Feb 2019 at 19:46, Simon Iten  wrote:

> So record the received data with a DAW, and post it, so others can try.
> Also try to play back the recorded 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 from a HW device, and I monitored the messages
>> both on Pd and MidiMonitor.
>>
>>
>> On Mon, 11 Feb 2019 at 12:59, Lucas Cordiviola 
>> wrote:
>>
>>> So you are sending sysex to Pd without any hardware? Just from virtual
>>> devices on the same Pc?
>>>
>>>
>>> Mensaje 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,
>>> Mario
>>>
>>> Sent from my WIKO U PULSE LITE
>>> On 11 Feb 2019 12:17, Lucas Cordiviola 
>>>  wrote:
>>>
>>> Do you have the same trouble with other software?
>>>
>>> It could be that you are exceeding the bandwidth of the MIDI hardware.
>>>
>>> Describe your connection:
>>>
>>> drummachine
>>> |
>>> midicable
>>> |
>>> midiin-jack on the sound card
>>> |
>>> Pd
>>>
>>> In other words: How are you sending sysex to Pd ?
>>>
>>>
>>> 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 [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-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] 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 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 over MIDI DIN, there are some limitations. The max you
> can cope with is roughly 3 bytes per msec (see MIDI HW baudrate), then of
> course the HW device would probably have some internal buffer to use in
> case it receives more msg than can actually handle.
> In terms of USB MIDI the bandwidth is way bigger than that. We are talking
> about 12 Mbit per second for a USB 1.0 device (let's say a class compliant
> device that then doesn't use any special driver). I remember I found once
> in the portmidi source code (
> https://sourceforge.net/projects/portmedia/files/portmidi/217/ -
> pmmacosxcm.c) a comment that says:
>
> /* maximum overall data rate (OS X limit is 15000 bytes/second) */
> and then
> #define MAX_BYTES_PER_S 14000
>
> I'm assuming other OSs would deal with something at least similar to that
> (I know Windows is not as good as MacOS on that, and unfortunately Linux
> with ALSA neither).
> In my case I'm using and class compliant HW device connected via USB.
> I know for sure MidiMonitor, Max/MSP and Python (using python-rtmidi) can
> handle this data.
> I'll try to create something we can use to test this and open an issue on
> github.
>
> Cheers,
> Mario
>
>
>
>
> On Mon, 11 Feb 2019 at 15:19, Lucas Cordiviola 
> wrote:
>
>> I did a test patch (attached)
>>
>> - I can send 7 byte sysex messages up to every 3ms
>>
>> - I can send noteout up to every 2ms
>>
>> This tests gave same results if using a midicable (cable loop on the
>> sound-card) or using a virtual driver.
>>
>>
>>
>> Mensaje telepatico asistido por maquinas.
>>
>> On 2/11/2019 10:55 AM, Dan Wilcox wrote:
>>
>> (responding again in thread)
>>
>> It is most likely a bug, maybe introduced in the MIDI overhaul I did for
>> 0.48. Does the same issue occur in 0.47?
>>
>> Can make a *re-produceable* patch and/or project for testing and open an
>> issue on the pure-data Github repo? The simplest thing for me would be the
>> syses messages you're sending as bytes.
>>
>> You could also check the output of the midi tester patch I added:
>>
>> Browser -> Pure Data/7.stuff/tools/miditester.pd
>>
>> 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 video that shows the issue:
>>> https://vimeo.com/316526250
>>> it's a private video, the pass is: sysexissue
>>> Does anybody know what could cause this behavior and if it's possible to
>>> 'fix it'?
>>> The first time I reported it, it was when I stumbled on this using my
>>> personal Linux machine and Miller Puckette suggested to change the MIDI
>>> buffer in the source code, but unfortunately also setting that to
>>> something
>>> insane like 2^20, the issue was still there.
>>> Now I double checked on MacOS Sierra and Windows 10 and it is the same.
>>>
>>> Cheers,
>>> Mario
>>
>>
>> --
>> Dan Wilcox
>> @danomatika
>> danomatika.com
>> robotcowboy.com
>>
>> ___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

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 over MIDI DIN, there are some limitations. The max you
can cope with is roughly 3 bytes per msec (see MIDI HW baudrate), then of
course the HW device would probably have some internal buffer to use in
case it receives more msg than can actually handle.
In terms of USB MIDI the bandwidth is way bigger than that. We are talking
about 12 Mbit per second for a USB 1.0 device (let's say a class compliant
device that then doesn't use any special driver). I remember I found once
in the portmidi source code (
https://sourceforge.net/projects/portmedia/files/portmidi/217/ -
pmmacosxcm.c) a comment that says:

/* maximum overall data rate (OS X limit is 15000 bytes/second) */
and then
#define MAX_BYTES_PER_S 14000

I'm assuming other OSs would deal with something at least similar to that
(I know Windows is not as good as MacOS on that, and unfortunately Linux
with ALSA neither).
In my case I'm using and class compliant HW device connected via USB.
I know for sure MidiMonitor, Max/MSP and Python (using python-rtmidi) can
handle this data.
I'll try to create something we can use to test this and open an issue on
github.

Cheers,
Mario

On Mon, 11 Feb 2019 at 15:19, Lucas Cordiviola 
wrote:

> I did a test patch (attached)
>
> - I can send 7 byte sysex messages up to every 3ms
>
> - I can send noteout up to every 2ms
>
> This tests gave same results if using a midicable (cable loop on the
> sound-card) or using a virtual driver.
>
>
>
> Mensaje telepatico asistido por maquinas.
>
> On 2/11/2019 10:55 AM, Dan Wilcox wrote:
>
> (responding again in thread)
>
> It is most likely a bug, maybe introduced in the MIDI overhaul I did for
> 0.48. Does the same issue occur in 0.47?
>
> Can make a *re-produceable* patch and/or project for testing and open an
> issue on the pure-data Github repo? The simplest thing for me would be the
> syses messages you're sending as bytes.
>
> You could also check the output of the midi tester patch I added:
>
> Browser -> Pure Data/7.stuff/tools/miditester.pd
>
> 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 video that shows the issue:
>> https://vimeo.com/316526250
>> it's a private video, the pass is: sysexissue
>> Does anybody know what could cause this behavior and if it's possible to
>> 'fix it'?
>> The first time I reported it, it was when I stumbled on this using my
>> personal Linux machine and Miller Puckette suggested to change the MIDI
>> buffer in the source code, but unfortunately also setting that to
>> something
>> insane like 2^20, the issue was still there.
>> Now I double checked on MacOS Sierra and Windows 10 and it is the same.
>>
>> Cheers,
>> Mario
>
>
> --
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
> ___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

Re: [PD] SysEx In issue

Hi Lucas,

Nope, I'm receiving MIDI from a HW device, and I monitored the messages
both on Pd and MidiMonitor.


On Mon, 11 Feb 2019 at 12:59, Lucas Cordiviola 
wrote:

> So you are sending sysex to Pd without any hardware? Just from virtual
> devices on the same Pc?
>
>
> Mensaje 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,
> Mario
>
> Sent from my WIKO U PULSE LITE
> On 11 Feb 2019 12:17, Lucas Cordiviola 
>  wrote:
>
> Do you have the same trouble with other software?
>
> It could be that you are exceeding the bandwidth of the MIDI hardware.
>
> Describe your connection:
>
> drummachine
> |
> midicable
> |
> midiin-jack on the sound card
> |
> Pd
>
> In other words: How are you sending sysex to Pd ?
>
>
> 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 [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-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

Re: [PD] SysEx In issue

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,
Mario

Sent from my WIKO U PULSE LITEOn 11 Feb 2019 12:17, Lucas Cordiviola 
 wrote:
>
> Do you have the same trouble with other software?
>
> It could be that you are exceeding the bandwidth of the MIDI hardware.
>
> Describe your connection:
>
> drummachine
> |
> midicable
> |
> midiin-jack on the sound card
> |
> Pd
>
> In other words: How are you sending sysex to Pd ?
>
>
> 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 
>> [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-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] 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-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[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 video that shows the issue:
https://vimeo.com/316526250
it's a private video, the pass is: sysexissue
Does anybody know what could cause this behavior and if it's possible to
'fix it'?
The first time I reported it, it was when I stumbled on this using my
personal Linux machine and Miller Puckette suggested to change the MIDI
buffer in the source code, but unfortunately also setting that to something
insane like 2^20, the issue was still there.
Now I double checked on MacOS Sierra and Windows 10 and it is the same.

Cheers,
Mario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2019-01-31 Thread Mario Buoninfante

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, which one is the most accurate? If this
question is applicable.

Cheers,
Mario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2019-01-21 Thread Mario Buoninfante

Hi Miller,

Thanks for the clarification. Having soundfiler able to read binary files would 
be great. In fact at the end of the day, I was trying to replace the external 
[binfile] that does exactly that.

Cheers,
Mario

Sent from my WIKO U PULSE LITEOn 20 Jan 2019 23:34, Miller Puckette 
 wrote:
>
> The trouble is probably the presence of a '{' character in the file. 
> But there will be other problems - ASCII NULL characters will simply 
> terminate the string early, and semicolons, spaces, and commas will 
> confuse things. 
>
> Somewhere on my long do-list is an idea 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 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 
> > missing (ie select all the file in Atom, copy and paste in [text]). 
> > When loading the file I've got no error, but then when I open the [text] 
> > window, this is returned on the console: 
> > 
> > (Tcl) UNHANDLED ERROR: extra characters after close-brace 
> > while executing 
> > "pdtk_textwindow_append .x100617310 {d 0 iM @?, f h I R kQ, [  ), Y Q 
> > Y1 
> > -" ( , XFN `  8 ) 6{` )  ) ; 
> > } 
> > pdtk_textwindow_append .x1006173..." 
> > ("uplevel" body line 39) 
> > invoked from within 
> > "uplevel #0 $docmds 
> > 
> > I know, it's a kind of a weird thing trying to read SysEx files in this way 
> > and probably it's just me trying to do something with the wrong tool. 
> > But weirdly enough the sequences of characters I cannot copy and paste from 
> > Atom, can then be directly typed in the [text] window. 
> > I suspect this has to do with the character encoding. 
> > Does anyone know why [text] behave this way? 
> > 
> > Cheers, 
> > Mario 
>
> > ___ 
> > 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] [text] issue reading SysEx files

2019-01-18 Thread Mario Buoninfante

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
missing (ie select all the file in Atom, copy and paste in [text]).
When loading the file I've got no error, but then when I open the [text]
window, this is returned on the console:

(Tcl) UNHANDLED ERROR: extra characters after close-brace
while executing
"pdtk_textwindow_append .x100617310 {d 0 iM @?, f h I R kQ, [ ÷ð ), Y Q Y1
-" ( , XFN `  8 ) 6{` )  ) ;
}
pdtk_textwindow_append .x1006173..."
("uplevel" body line 39)
invoked from within
"uplevel #0 $docmds

I know, it's a kind of a weird thing trying to read SysEx files in this way
and probably it's just me trying to do something with the wrong tool.
But weirdly enough the sequences of characters I cannot copy and paste from
Atom, can then be directly typed in the [text] window.
I suspect this has to do with the character encoding.
Does anyone know why [text] behave this way?

Cheers,
Mario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2019-01-15 Thread mario buoninfante

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 case Pd is already open, the path when using [symbol ./( is 
"/home/UserName"


--
Electronic Musician, Creative Coder, QA Engineer
https://vimeo.com/creativecodingsalerno
http://mbuoninfante.tumblr.com/
https://github.com/mariobuoninfante
https://bitbucket.org/mariobuoninfante/




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2019-01-15 Thread Mario Buoninfante

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 -> 
https://lists.puredata.info/listinfo/pd-list

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

2019-01-15 Thread Mario Buoninfante

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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2018-07-28 Thread mario buoninfante


Hi Christof,


thanks a lot for this :D
in the meanwhile I looked at Miller Puckette's book, and in fact what 
you described is reported also there.


thanks for your explanation.


cheers,

Mario


On 28/07/18 12:58, Christof Ressi wrote:

Hi Mario,

you're right, [del], [pipe] (and [metro] btw) themselves are unproblematic 
because clocks are timestamped (and therefore [timer] will show the correct 
logical time). the problem really lies in the conversion from/to audio, as you 
noted correctly.

for the sake of completeness:

with every scheduler tick, Pd checks for clock timeouts, polls the GUI and does 
64 samples of DSP computation.
now let's say a canvas has [block~ 256]: in the first 3 schedular ticks nothing happens 
expect for [inlet~] buffering, only at the 4th tick we actually do the 256 samples of 
DSP. but this means that clock timeouts can only happen before those 256 samples - not in 
between! still, clock timeouts happen at the same "rate" as DSP computation.
now imagine this canvas has a subcanvas with [block~ 64]: everytime the parent 
canvas (256 samples) is processed, the subcanvas (64 samples) gets processed 4 
times in a row and clock timeouts effectively only happen every 4 blocks. but 
this means DSP computation and clock timeouts are out of sync and even 
sub-sample correct objects like [vline~] might behave strangely.

eventually, the number of samples between clock timeouts for a canvas and all 
its subcanvasses is determined by the 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 Ressi" 
Cc: Pd-List 
Betreff: Re: Aw: [PD] triggering [print~] faster than every 64 samples

Hi Christof,


thanks for that, this clarifies quite a lot of things. that said it
seems that objects like [del] and [pipe] can deal with this kind of
situations (ie [del 1 10 samp]). the "issue" seems to appear when you
start using "hybrid" objects (control signal to audio signal or the
other way around). am I right assuming that?


cheers,

Mario


On 28/07/18 10:43, Christof Ressi wrote:

the technical reason is that clock timeouts can't happen in intervals smaller 
than 64 samples (pd's scheduler blocksize) *), so any objects relying on clocks 
(e.g. [print~], [bang~], [line~], [vline~], [del], [pipe], etc) might not work 
as expected.

Christof

*) more generally, clock timeouts are limited to the largest parent blocksize. 
see attached patch.


Gesendet: Samstag, 28. Juli 2018 um 10:45 Uhr
Von: "mario buoninfante" 
An: Pd-List 
Betreff: [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 receives a bang
every sample but prints every 64 (default block size).

can you guys help me understanding why? I'm pretty sure I'm missing
something here :D


cheers,

Mario


___
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] triggering [print~] faster than every 64 samples

2018-07-28 Thread mario buoninfante


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 receives a bang 
every sample but prints every 64 (default block size).


can you guys help me understanding why? I'm pretty sure I'm missing 
something here :D



cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2018-07-11 Thread Mario Buoninfante

Hi Matt,

yap, I got your point guys, and as I said I never rely on this kind of
things (that's why [trigger] extists ;) ), so we're on the same page here.
but I would disagree with the "there is no point in trying to understand
how it works" part. I think it's important to be aware of the tool. for
example, the way I came across this is while I was debugging a big patch. I
think that knowing about this "order of operation" thing would have helped
me understanding what's going on (because there's a rule behind it, that of
course like you said could change in the future - risky thing changing this
kind of things in my view - but it's matter of fact now is there) . at the
end of the day I found the issue in my patch, but almost certainly would
have taken me less time if I knew this.

cheers,
Mario

On 10 July 2018 at 21:05, Matt Davey  wrote:

> iohannes’ 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 Tuesday, July 10, 2018, mario buoninfante 
> wrote:
>
>> 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 [t] to be sure
>> that the oder of operation is correct, but I also know that there's a
>> "rule" about the order of connection. so my question would be, is there any
>> rule behind the [send] and [return] behavior?
>>
>>
>> cheers,
>>
>> Mario
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2018-07-10 Thread mario buoninfante


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 
[t] to be sure that the oder of operation is correct, but I also know 
that there's a "rule" about the order of connection. so my question 
would be, is there any rule behind the [send] and [return] behavior?



cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2018-07-10 Thread mario buoninfante


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 what happens when you connect an object to 2 different objects 
(without using any [trigger] and any "wireless connection"). in this 
case the first one connected will receive the message first.


is that a bug?

I'm on Pd 0.48.1


cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2018-06-16 Thread mario buoninfante


Hi Dan,

the last patch I tried has only a [midiin] connected to a counter made 
with Pd objects in Vanilla, so that I could count the number of incoming 
messages. Unfortunately I cannot give you (at least at the moment) the 
sysex file, since is sent by a piece of hardware. my sneaky suspicious 
is that the issue is "rate related". It looks to me like Pd tries to 
keep up but without any success.


another thing that pops up in my mind is the sysex length. in my case 
the messages are 256 bytes long, do we have any restriction in Pd?


anyway I'll try to capture the sysex using a different tool and send it 
over to you.



cheers,

Mario


On 16/06/18 23:00, Dan Wilcox wrote:

a couple things:

* Do you have a patch or set up that causes this?

* Does it happen only based on a certain length or does it only happen 
to a certain message?


* Can you send me the raw byte 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 receiving sysex (pt.2)
Message-ID:
<mailto:CAHs=M8RCrCw5t1EO9iS_BKVL3J=6snrhejxiwxvbwfvwsyu...@mail.gmail.com>>

Content-Type: text/plain; charset="utf-8"

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 make it 0x10,
for instance
*>* (a million-ish).
*> >* To easily recompile Pd on a Mac, install the developer package 
(compiler

*>* chain which I think is now called Xcode), open a shell, Cd to
*>* Pd-x.app/Contents/Resources/src, edit s_midi.c, and type "make".
*>

I tried recompiling both on Linux (Ubuntu Studio 16.04) and MacOS 
(Sierra)
but unfortunately without any success. I mean, I've been able to 
recompile

it, but the issue's still there. moreover I couldn't find s_midi.c in

*Pd-x.app/Contents/Resources/src*

so I had to use the source code.
basically I'm sending (relatively) big sysex to Pd as fast as 
possible and
I noticed Pd drops most of them. I'm collecting few hundreds byte on 
top of

thousands.
did I miss something?
does anyone experienced something like that? any suggestion?

cheers,
Mario



Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

2018-06-15 Thread Mario Buoninfante

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 make it 0x10,
for instance
*>* (a million-ish).
*> >* To easily recompile Pd on a Mac, install the developer package (compiler
*>* chain which I think is now called Xcode), open a shell, Cd to
*>* Pd-x.app/Contents/Resources/src, edit s_midi.c, and type "make".
*>

I tried recompiling both on Linux (Ubuntu Studio 16.04) and MacOS (Sierra)
but unfortunately without any success. I mean, I've been able to recompile
it, but the issue's still there. moreover I couldn't find s_midi.c in

*Pd-x.app/Contents/Resources/src*

so I had to use the source code.
basically I'm sending (relatively) big sysex to Pd as fast as possible and
I noticed Pd drops most of them. I'm collecting few hundreds byte on top of
thousands.
did I miss something?
does anyone experienced something like that? any suggestion?

cheers,
Mario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] add inlets to [ctlin]

2018-04-01 Thread mario buoninfante


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 -> 
https://lists.puredata.info/listinfo/pd-list

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

2018-04-01 Thread mario buoninfante


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, 
Python, etc ) would be a better option.


then, about having the possibility to write sample level patch in an 
optimized way sounds amazing. I'm just wondering if it wouldn't be a 
better idea trying to better integrate Faust. my only concern is about 
maintainability of this new object family, JIT (in case we're talking 
about a specific object family). Faust is already out there and works 
pretty fine plus has an active and big community that constantly works 
to improve and update it.


last but not the least, multithreading is obviously a good thing, but 
honestly do we really need to have something similar to what you 
described? don't get me wrong, the idea is cool and I only want to 
discuss these ideas, not criticize them. but personally, and of course I 
know everyone has different approaches and different needs, I think 
there's still a lot to explore before "moving to a multithreading 
dimension". also if it's a totally different situation (different 
hardware and programming language), I keep thinking about most of the 
commercial products, musical instruments (also the most complex) that 
are single thread based.


mine of course are just thoughts.


cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] add inlets to [ctlin]

2018-04-01 Thread mario buoninfante


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 also the way it does it.


the talking piano is really cool, I didn't know it. but it doesn't look 
like "performances" are really important in this situation (it's not a 
kind o f live processing integrated into a most complex system where 
time stuff matters), otherwise I'm pretty sure an improvement on [ctlin] 
would be really appreciated :D kiddin'




cheers,

Mario





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] add inlets to [ctlin]

2018-03-31 Thread mario buoninfante


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 we're talking about (a couple of 
[spigot] and [==] in my case). in this scenario, every time a CC message 
is sent to the patch, all these objects are exercised ([ctlin] + 2 
[spigot] + 2 [==], all of them * 10). this wouldn't happen if [ctlin] 
had 2 inlets to set the arguments on the fly. all the processes would 
happen under the hood, within the 10 [ctlin] objects, without involving 
other objects.



cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] add inlets to [ctlin]

2018-03-31 Thread mario buoninfante


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
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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


sorry, I messed it up. what I was describing is the following:


1. launch Pd

2. click Ctrl+B to launch Browser

3. look for jit_expr and launch the help file

after that you can load jit/expr . but this is normal since in the help 
file there's a [declare] object.


but now I tried with [declare -lib jit_expr] and it perfectly works. 
sorry for the confusion



cheers,

Mario


On 18/03/18 17:11, Alex wrote:

Mario,

I'm a little confused. Were you successful loading the help patch and 
getting the objects to load there but not outside of the help patch or 
not at all?


-Alex

On Sun, 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.

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

but after that I'm able to load the object.

I'm using Pd 0.48.0 on Linux 64bit


cheers,

Mario


___
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
<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] [PD-announce] jit_expr 0.1: Just in time compiled expr/expr~/fexpr~

that's amazing Alex. really good job. I'll spend the next days pushing 
it to the limit :)


btw, I checked and using [declare -lib jit_expr] works fine.


cheers,

Mario


On 18/03/18 17:08, Alex wrote:
My understanding is the gen~ is a relatively constrained special 
purpose graphical patching environment for building expressions that 
are run at sample rate, and can maybe generate c++ code as well?


This is not _so_ much different but entirely textual and compiles 
directly to machine code, as of yet there is no way to output c++, but 
it seems like the comparison is fair.


-Alex


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 (btw, I know there's Faust that works with Pd).
anyway, super cool, I'll give it a try asap.


cheers,
Mario


___
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
<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] [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


but after that I'm able to load the object.

I'm using Pd 0.48.0 on Linux 64bit


cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[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


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] sysex messages


but still if I'm not wrong we don't deal with Active Sensing. am I wrong?


On 14/03/18 23:06, Dan Wilcox wrote:
It's probably not the changes to the alsa code but more likely those 
to the general MIDI parser in s_midi.c. It now handles all message 
types as well as realtime bytes within other 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 overhauled the MIDI handling so all message types can 
be sent/received, but I only made a "pretty good guess" with the 
ALSA interface as I didn't personally test 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 <mario.buoninfa...@gmail.com 
<mailto:mario.buoninfa...@gmail.com>>
Cc: Simon Iten <itensi...@gmail.com <mailto:itensi...@gmail.com>>, 
pd list <pd-l...@iem.at <mailto:pd-l...@iem.at>>

Subject: Re: [PD] sysex messages
Message-ID: <20180314222113.GL7620@elroy.localdomain 
<mailto:20180314222113.GL7620@elroy.localdomain>>

Content-Type: text/plain; charset=utf-8

Aha!  Yes, Dan Wilcox contributed a whole raft of changes to 
s_midi_alsa.c

August 2017.  So it looks like we're in the clear after all...

cheers
Miller



Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>








Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] sysex messages


it looks like your guess definitely worked :D


thanks,

Mario


On 14/03/18 22:32, Dan Wilcox wrote:
I essentially overhauled the MIDI handling so all message types can be 
sent/received, but I only made a "pretty good guess" with the ALSA 
interface as I didn't personally test 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 <mario.buoninfa...@gmail.com 
<mailto:mario.buoninfa...@gmail.com>>
Cc: Simon Iten <itensi...@gmail.com <mailto:itensi...@gmail.com>>, pd 
list <pd-l...@iem.at <mailto:pd-l...@iem.at>>

Subject: Re: [PD] sysex messages
Message-ID: <20180314222113.GL7620@elroy.localdomain 
<mailto:20180314222113.GL7620@elroy.localdomain>>

Content-Type: text/plain; charset=utf-8

Aha!  Yes, Dan Wilcox contributed a whole raft of changes to 
s_midi_alsa.c

August 2017.  So it looks like we're in the clear after all...

cheers
Miller



Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] sysex messages

amazing, this makes sense. now I'm just curious to have a look at the 
code and compare it with the latest version.


thanks for your help :D


cheers,

Mario


On 14/03/18 22:21, Miller Puckette wrote:

Aha!  Yes, Dan Wilcox contributed a whole raft of changes to s_midi_alsa.c
August 2017.  So 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, after chatting with another Pd user, I figured
it out that the problem doesn't occur on Pd 0.48.0 and 0.48.1 . but it does
occur on Pd 0.46.1, the version I was using when I discovered this.
so my suspect is that something changed in the code. I'll have a look at
github. does anyone know anything about that>


cheers,
Mario

On 14/03/18 21:49, Simon Iten wrote:

hi there,

i have sent sysex with puredata for some years now, and i never had any
problems, even with large chunks.
i have used attached abstraction to send sysex, maybe it helps?

midi IS a serial protocol, so 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
<mario.buoninfa...@gmail.com <mailto:mario.buoninfa...@gmail.com>>
wrote:

Hi Miller,

yap I'm using ALSA.

btw, I had a look at the source code (I want to clarify I'm not a C
programmer :) ) and from what I found in x_midi.c and s_midi.c, it
kind of make sense that [midiout] returns 1 byte at time.

it seems to me we're missing a way to detect outgoing sysex messages
(maybe having a dedicated object could help), so there's no way to
collect a sysex and send it out in one go (ie having an array to
return). I apologize for my trivial description of the "problem",
but this is what I think is causing this behaviour.


cheers,

Mario


On 13/03/18 04:37, Miller Puckette wrote:

Hi Mario -

Perhaps you said this in the previous message which I missed... are you
using ALSA MIDI system or OSS?

MIDI support has always been a problem in Pd... largely because I don't have
a lot of experience with it.

cheers
Miller

On Tue, Mar 13, 2018 at 12:04:00AM +, 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 On
messages with [midiout] seems to be in some way different then sending the
same message using [noteout].

when Note On is sent using [midiout], this will spit single bytes that are
recognized as single byte sysex messages by the MIDI monitors!

has anyone ever experienced the same?


cheers,

Mario


___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at <mailto: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

Re: [PD] sysex messages

yap I start thinking the same. also because I had a chat with a 
colleague who's a programmer, who told me that for example on MacOS 
there is a process called something like MIDI Manager which sits in the 
middle and buffers up all the messages, forwarding them to applications 
that are listening to the ports.


so probably this is what is missing (or simply working differently) on 
Linux with ALSA.



cheers,

Mario


On 14/03/18 21:53, Miller Puckette wrote:

This seems to be a specific problem with sysex-handling using linux/ALSA...
if you're using 'OSS' MIDI back end it should work fine.

Incidentally, I think the best fix would be to start using portmidi to address
linux/ALSA.

(An easier one would be to just use OSS but there are features in the ALSA
driver such as loopback that I think you can't get in OSS emulation, so
some MIDI users on linux are forced into the ALSA API.

cheers
Miller

On Wed, Mar 14, 2018 at 10:49:28PM +0100, Simon Iten wrote:

hi there,

i have sent sysex with puredata for some years now, and i never had any 
problems, even with large chunks.
i have used attached abstraction to send sysex, maybe it helps?

midi IS a serial protocol, so 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 <mario.buoninfa...@gmail.com> wrote:

Hi Miller,

yap I'm using ALSA.
btw, I had a look at the source code (I want to clarify I'm not a C programmer 
:) ) and from what I found in x_midi.c and s_midi.c, it kind of make sense that 
[midiout] returns 1 byte at time.

it seems to me we're missing a way to detect outgoing sysex messages (maybe having a 
dedicated object could help), so there's no way to collect a sysex and send it out in one 
go (ie having an array to return). I apologize for my trivial description of the 
"problem", but this is what I think is causing this behaviour.



cheers,

Mario


On 13/03/18 04:37, Miller Puckette wrote:

Hi Mario -

Perhaps you said this in the previous message which I missed... are you
using ALSA MIDI system or OSS?

MIDI support has always been a problem in Pd... largely because I don't have
a lot of experience with it.

cheers
Miller

On Tue, Mar 13, 2018 at 12:04:00AM +, 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 On
messages with [midiout] seems to be in some way different then sending the
same message using [noteout].

when Note On is sent using [midiout], this will spit single bytes that are
recognized as single byte sysex messages by the MIDI monitors!

has anyone ever experienced the same?


cheers,

Mario


___
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list 
<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



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] sysex messages


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, after chatting with another Pd user, I 
figured it out that the problem doesn't occur on Pd 0.48.0 and 0.48.1 . 
but it does  occur on Pd 0.46.1, the version I was using when I 
discovered this.
so my suspect is that something changed in the code. I'll have a look at 
github. does anyone know anything about that>



cheers,
Mario

On 14/03/18 21:49, Simon Iten wrote:

hi there,

i have sent sysex with puredata for some years now, and i never had 
any problems, even with large chunks.

i have used attached abstraction to send sysex, maybe it helps?

midi IS a serial protocol, so 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 
<mario.buoninfa...@gmail.com <mailto:mario.buoninfa...@gmail.com>> wrote:


Hi Miller,

yap I'm using ALSA.

btw, I had a look at the source code (I want to clarify I'm not a C 
programmer :) ) and from what I found in x_midi.c and s_midi.c, it 
kind of make sense that [midiout] returns 1 byte at time.


it seems to me we're missing a way to detect outgoing sysex messages 
(maybe having a dedicated object could help), so there's no way to 
collect a sysex and send it out in one go (ie having an array to 
return). I apologize for my trivial description of the "problem", but 
this is what I think is causing this behaviour.



cheers,

Mario


On 13/03/18 04:37, Miller Puckette wrote:

Hi Mario -

Perhaps you said this in the previous message which I missed... are you
using ALSA MIDI system or OSS?

MIDI support has always been a problem in Pd... largely because I don't have
a lot of experience with it.

cheers
Miller

On Tue, Mar 13, 2018 at 12:04:00AM +, 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 On
messages with [midiout] seems to be in some way different then sending the
same message using [noteout].

when Note On is sent using [midiout], this will spit single bytes that are
recognized as single byte sysex messages by the MIDI monitors!

has anyone ever experienced the same?


cheers,

Mario


___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at <mailto: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] sysex messages


Hi Miller,

yap I'm using ALSA.

btw, I had a look at the source code (I want to clarify I'm not a C 
programmer :) ) and from what I found in x_midi.c and s_midi.c, it kind 
of make sense that [midiout] returns 1 byte at time.


it seems to me we're missing a way to detect outgoing sysex messages 
(maybe having a dedicated object could help), so there's no way to 
collect a sysex and send it out in one go (ie having an array to 
return). I apologize for my trivial description of the "problem", but 
this is what I think is causing this behaviour.



cheers,

Mario


On 13/03/18 04:37, Miller Puckette wrote:

Hi Mario -

Perhaps you said this in the previous message which I missed... are you
using ALSA MIDI system or OSS?

MIDI support has always been a problem in Pd... largely because I don't have
a lot of experience with it.

cheers
Miller

On Tue, Mar 13, 2018 at 12:04: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 On
messages with [midiout] seems to be in some way different then sending the
same message using [noteout].

when Note On is sent using [midiout], this will spit single bytes that are
recognized as single byte sysex messages by the MIDI monitors!

has anyone ever experienced the same?


cheers,

Mario





___
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] sysex messages

2018-03-12 Thread mario buoninfante


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 in some way different then 
sending the same message using [noteout].


when Note On is sent using [midiout], this will spit single bytes that 
are recognized as single byte sysex messages by the MIDI monitors!


has anyone ever experienced the same?


cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Pd FLOSS manual update

2018-02-27 Thread mario buoninfante




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 expanding it.


the amount of work is quite significant and I think there are some 
important decisions to take, considering that huge changes have been 
introduced since then (no more Pd-extended, so which Pd version should 
be used for the manual - I'd say Vanilla since is the only one that for 
sure won't stop, but of course it's possible to add paragraphs about 
Pd-L2Ork and Purr Data).


I think the first thing would be "building a team" (I mean, see who 
wanna get involved) so that we can start planning (what should be 
updated, changed, added and so on).



cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] sysex messages

2018-02-23 Thread Mario Buoninfante

Hi Marco,

I just wanna point out that I haven't got issues with Pd, no problem at
all. I can easily work with Sysex in various way and of course also the way
you described. mine was more a let's call it curiosity. also because I
think that the possibility to directly send a list to [midiout], 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. and the
> way that Circuit sends these info is why sysex. so I'm just dumping data
> and monitoring.
>
> On 02/22/2018 10:37 PM, Alex wrote:
>
> Oh okay, I get it.
> I'm 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> wrote:
>
>> yap, this makes sense. I imagined Gmidimonitor does that. but why is not
>> parsing midi from Pd?
>>
>> sorry, maybe I'm just missing the point, but I'm really trying to get my
>> head around with that ;)
>>
>>
>> cheers
>>
>>
>>
>> On 02/22/2018 10:29 PM, Christof Ressi wrote:
>>
>>> don't confuse MIDI messages with the individual bytes which make up 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" <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 different piece of
>>> code that generates MIDI (Pd and Hardware synth).
>>> for example I just monitored (via USB) my Novation Circuit (a groovebox)
>>> and Gmidimonitor receives messages 81 bytes long. with Pd as I said is
>>> always 1 byte.
>>> now my question would be, how is this possible?
>>> I'm sure Circuit sends sysex 81 bytes long, so I know that this is
>>> correct, but still I don't know why Pd doesn't allow something like that.
>>>   cheers,
>>> Mario
>>>   On 02/22/2018 09:58 PM, Alex wrote:
>>>
>>> MIDI is a serial protocol, individual bits running down a single line,
>>> we now also have USB midi which is a little bit different than that but
>>> usually that is abstracted for you.The software monitor you're using likely
>>> groups these for you but in reality you simply have a stream 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 think that also using your abstraction Pd
>>> will spit out 1 byte per time (I didn't check it, but I assume that cause
>>> it's not an external in C).
>>> about MIDI if I'm not wrong, bytes are grouped in accord with the type
>>> of message, ie Note on/off and CC are 3 bytes messages, channel pressure
>>> and program change are 2 bytes, sysex have variable length and so on. and I
>>> presume they're sent out in group.
>>> in fact when I monitor MIDI messages coming for certain applications
>>> (I'm on Linux and I'm using Gmidimonitor) the console tells me the sysex
>>> size in bytes. so, with Pd the size is always 1 byte, but with other
>>> programming languages and softwares is variable and goes in accord with the
>>> sysex I generated.
>>>   cheers,
>>> Mario
>>>
>>>
>>> On 02/22/2018 09:34 PM, Alex wrote:
>>>
>>> I haven't tested in a while but I wrote an abstraction to take a list,
>>> wrap it in the sysex start and end and output it as individual bytes:
>>> https://github.com/x37v/pure_data[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 know if there's a way

Re: [PD] sysex messages

yap I'm sending sysex from Circuit. I'm using Components a Novation 
website that allows you to store patches and session from Circuit. and 
the way that Circuit sends these info is why sysex. so I'm just dumping 
data and monitoring.



On 02/22/2018 10:37 PM, Alex wrote:

Oh okay, I get it.
I'm 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 midi from Pd?

sorry, maybe I'm just missing the point, but I'm really trying to
get my head around with that ;)


cheers



On 02/22/2018 10:29 PM, Christof Ressi wrote:

don't confuse MIDI messages with the individual bytes which
make up 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" <mario.buoninfa...@gmail.com
<mailto:mario.buoninfa...@gmail.com>>
An: Alex <x37v.a...@gmail.com <mailto:x37v.a...@gmail.com>>
Cc: pd-list@lists.iem.at <mailto: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 different piece of code that generates MIDI (Pd and Hardware
synth).
for example I just monitored (via USB) my Novation Circuit (a
groovebox) and Gmidimonitor receives messages 81 bytes long.
with Pd as I said is always 1 byte.
now my question would be, how is this possible?
I'm sure Circuit sends sysex 81 bytes long, so I know that
this is correct, but still I don't know why Pd doesn't allow
something like that.
  cheers,
Mario
  On 02/22/2018 09:58 PM, Alex wrote:

MIDI is a serial protocol, individual bits running down a
single line, we now also have USB midi which is a little bit
different than that but usually that is abstracted for you.The
software monitor you're using likely groups these for you but
in reality you simply have a stream 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>[mailto:mario.buoninfa...@gmail.com
<mailto:mario.buoninfa...@gmail.com>]> wrote:
Hi Alex,
  thanks for your reply. I think that also using your
abstraction Pd will spit out 1 byte per time (I didn't check
it, but I assume that cause it's not an external in C).
about MIDI if I'm not wrong, bytes are grouped in accord with
the type of message, ie Note on/off and CC are 3 bytes
messages, channel pressure and program change are 2 bytes,
sysex have variable length and so on. and I presume they're
sent out in group.
in fact when I monitor MIDI messages coming for certain
applications (I'm on Linux and I'm using Gmidimonitor) the
console tells me the sysex size in bytes. so, with Pd the size
is always 1 byte, but with other programming languages and
softwares is variable and goes in accord with the sysex I
generated.
  cheers,
Mario


On 02/22/2018 09:34 PM, Alex wrote:

I haven't tested in a while but I wrote an abstraction to take
a list, wrap it in the sysex start and end and output it as
individual bytes:
https://github.com/x37v/pure_data[https://github.com/x37v/pure_data]

<https://github.com/x37v/pure_data%5Bhttps://github.com/x37v/pure_data%5D>
  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>[mailto:mario.buoninfa...@gmail.com
<mailto:mario.buoninfa...@gmail.com>]> wrote: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-list@lists.iem.at
<mailto:Pd-list@lists.iem.at>[mailto:Pd-list@lists.iem.at
<mailto:Pd-list@lists.iem.at>] mailing list
UNSUBSCRIBE a

Re: [PD] sysex messages

the way I'm generating sysex in Pd is the following:

[list of bytes which starts with 240 and ends with 247(

[cyclone/iter 1]

[midiout 1]

On 02/22/2018 10:35 PM, Christof Ressi wrote:

are you sure you're correctly assembling your sysex messages in Pd? you could
use [sysexin] 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...@gmx.at>, pd-list <pd-l...@iem.at>
Betreff: Re: Aw: Re: [PD] sysex messages

yap, this makes sense. I imagined Gmidimonitor does that. but why is not
parsing midi from Pd?

sorry, maybe I'm just missing the point, but I'm really trying to get my
head around with that ;)

cheers

On 02/22/2018 10:29 PM, Christof Ressi wrote:

don't confuse MIDI messages with the individual bytes which make up 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" <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 different piece of code that
generates MIDI (Pd and Hardware synth).
for example I just monitored (via USB) my Novation Circuit (a groovebox) and
Gmidimonitor receives messages 81 bytes long. with Pd as I said is always 1
byte.
now my question would be, how is this possible?
I'm sure Circuit sends sysex 81 bytes long, so I know that this is correct, but
still I don't know why Pd doesn't allow something like that.

cheers,

Mario

On 02/22/2018 09:58 PM, Alex wrote:

MIDI is a serial protocol, individual bits running down a single line, we now
also have USB midi which is a little bit different than that but usually that
is abstracted for you.The software monitor you're using likely groups these for
you but in reality you simply have a stream 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 think that also using your abstraction Pd will spit out 1 byte per time (I didn't check it, but I assume that cause it's not an external in C).

about MIDI if I'm not wrong, bytes are grouped in accord with the type of
message, ie Note on/off and CC are 3 bytes messages, channel pressure and
program change are 2 bytes, sysex have variable length and so on. and I presume
they're sent out in group.
in fact when I monitor MIDI messages coming for certain applications (I'm on
Linux and I'm using Gmidimonitor) the console tells me the sysex size in bytes.
so, with Pd the size is always 1 byte, but with other programming languages and
softwares is variable and goes in accord with the sysex I generated.

cheers,

Mario

On 02/22/2018 09:34 PM, Alex wrote:

I haven't tested in a while but I wrote an abstraction to take a list, wrap it
in the sysex start and end and output it as individual bytes:
https://github.com/x37v/pure_data[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 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-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list[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[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] sysex messages

yes I'm sure, and I also monitored my Circuit on Mac with Midi Monitor,
everything is fine. then I'm sure that [sysexin] will spit out 1 byte at
time.

On 02/22/2018 10:35 PM, Christof Ressi wrote:

yap, this makes sense. I imagined Gmidimonitor does that. but why is not
parsing midi from Pd?

sorry, maybe I'm just missing the point, but I'm really trying to get my
head around with that ;)

cheers

On 02/22/2018 10:29 PM, Christof Ressi wrote:

Gesendet: Donnerstag, 22. Februar 2018 um 23:05 Uhr
Von: "mario buoninfante" <mario.buoninfa...@gmail.com>
An: Alex <x37v.a...@gmail.com>
Cc: pd-list@lists.iem.at
Betreff: Re: [PD] sysex messages

cheers,

Mario

On 02/22/2018 09:58 PM, Alex wrote:

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 think that also using your abstraction Pd will spit out 1 byte per time (I didn't check it, but I assume that cause it's not an external in C).

cheers,

Mario

On 02/22/2018 09:34 PM, Alex wrote:

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 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-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list

Re: [PD] sysex messages

funny thing I created a new patch with only a numberbox connected to 
[midiout 1], every value I typed will generate a sysex msg??


I don't entirely understand that


On 02/22/2018 10:29 PM, Christof Ressi wrote:

don't confuse MIDI messages with the individual bytes which make up 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" <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 different piece of code that 
generates MIDI (Pd and Hardware synth).
for example I just monitored (via USB) my Novation Circuit (a groovebox) and 
Gmidimonitor receives messages 81 bytes long. with Pd as I said is always 1 
byte.
now my question would be, how is this possible?
I'm sure Circuit sends sysex 81 bytes long, so I know that this is correct, but 
still I don't know why Pd doesn't allow something like that.
  
cheers,

Mario
  
On 02/22/2018 09:58 PM, Alex wrote:


MIDI is a serial protocol, individual bits running down a single line, we now 
also have USB midi which is a little bit different than that but usually that 
is abstracted for you.The software monitor you're using likely groups these for 
you but in reality you simply have a stream 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 think that also using your abstraction Pd will spit out 1 byte per time (I didn't check it, but I assume that cause it's not an external in C).

about MIDI if I'm not wrong, bytes are grouped in accord with the type of 
message, ie Note on/off and CC are 3 bytes messages, channel pressure and 
program change are 2 bytes, sysex have variable length and so on. and I presume 
they're sent out in group.
in fact when I monitor MIDI messages coming for certain applications (I'm on 
Linux and I'm using Gmidimonitor) the console tells me the sysex size in bytes. 
so, with Pd the size is always 1 byte, but with other programming languages and 
softwares is variable and goes in accord with the sysex I generated.
  
cheers,

Mario

  


On 02/22/2018 09:34 PM, Alex wrote:

I haven't tested in a while but I wrote an abstraction to take a list, wrap it 
in the sysex start and end and output it as individual bytes: 
https://github.com/x37v/pure_data[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 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-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[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[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] sysex messages

yap, this makes sense. I imagined Gmidimonitor does that. but why is not
parsing midi from Pd?

sorry, maybe I'm just missing the point, but I'm really trying to get my
head around with that ;)

cheers

On 02/22/2018 10:29 PM, Christof Ressi wrote:

Gesendet: Donnerstag, 22. Februar 2018 um 23:05 Uhr
Von: "mario buoninfante" <mario.buoninfa...@gmail.com>
An: Alex <x37v.a...@gmail.com>
Cc: pd-list@lists.iem.at
Betreff: Re: [PD] sysex messages

cheers,

Mario

On 02/22/2018 09:58 PM, Alex wrote:

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 think that also using your abstraction Pd will spit out 1 byte per time (I didn't check it, but I assume that cause it's not an external in C).

cheers,

Mario

On 02/22/2018 09:34 PM, Alex wrote:

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 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-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list

Re: [PD] sysex messages


Hi Ryan,


Circuit is sending MIDI via USB, while I'm routing Pd via Jack on Linux.


cheers


On 02/22/2018 10:25 PM, Ryan Smith wrote:

Are you using the hardware midi ports on the Circuit or all through
USB? The USB midi specs are slightly different when it comes to sysex
messages if I recall 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 time.
I was wondering why there's a difference between 2 different piece of code
that generates MIDI (Pd and Hardware synth).

for example I just monitored (via USB) my Novation Circuit (a groovebox) and
Gmidimonitor receives messages 81 bytes long. with Pd as I said is always 1
byte.

now my question would be, how is this possible?

I'm sure Circuit sends sysex 81 bytes long, so I know that this is correct,
but still I don't know why Pd doesn't allow something like that.


cheers,

Mario


On 02/22/2018 09:58 PM, Alex wrote:

MIDI is a serial protocol, individual bits running down a single line, we
now also have USB midi which is a little bit different than that but usually
that is abstracted for you.
The software monitor you're using likely groups these for you but in reality
you simply have a stream 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> wrote:

Hi Alex,


thanks for your reply. I think that also using your abstraction Pd will
spit out 1 byte per time (I didn't check it, but I assume that cause it's
not an external in C).

about MIDI if I'm not wrong, bytes are grouped in accord with the type of
message, ie Note on/off and CC are 3 bytes messages, channel pressure and
program change are 2 bytes, sysex have variable length and so on. and I
presume they're sent out in group.

in fact when I monitor MIDI messages coming for certain applications (I'm
on Linux and I'm using Gmidimonitor) the console tells me the sysex size in
bytes. so, with Pd the size is always 1 byte, but with other programming
languages and softwares is variable and goes in accord with the sysex I
generated.


cheers,

Mario


On 02/22/2018 09:34 PM, Alex wrote:

I haven't tested in a while but I wrote an abstraction to take a list,
wrap 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> wrote:

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-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

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 different piece 
of code that generates MIDI (Pd and Hardware synth).


for example I just monitored (via USB) my Novation Circuit (a groovebox) 
and Gmidimonitor receives messages 81 bytes long. with Pd as I said is 
always 1 byte.


now my question would be, how is this possible?

I'm sure Circuit sends sysex 81 bytes long, so I know that this is 
correct, but still I don't know why Pd doesn't allow something like that.



cheers,

Mario


On 02/22/2018 09:58 PM, Alex wrote:
MIDI is a serial protocol, individual bits running down a single line, 
we now also have USB midi which is a little bit different than that 
but usually that is abstracted for you.
The software monitor you're using likely groups these for you but in 
reality you simply have a stream 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 think that also using your abstraction Pd
will spit out 1 byte per time (I didn't check it, but I assume
that cause it's not an external in C).

about MIDI if I'm not wrong, bytes are grouped in accord with the
type of message, ie Note on/off and CC are 3 bytes messages,
channel pressure and program change are 2 bytes, sysex have
variable length and so on. and I presume they're sent out in group.

in fact when I monitor MIDI messages coming for certain
applications (I'm on Linux and I'm using Gmidimonitor) the console
tells me the sysex size in bytes. so, with Pd the size is always 1
byte, but with other programming languages and softwares is
variable and goes in accord with the sysex I generated.


cheers,

Mario


On 02/22/2018 09:34 PM, Alex wrote:

I haven't tested in a while but I wrote an abstraction to take a
list, wrap it in the sysex start and end and output it as
individual bytes: https://github.com/x37v/pure_data
<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 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-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
<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] sysex messages


Hi Alex,


thanks for your reply. I think that also using your abstraction Pd will 
spit out 1 byte per time (I didn't check it, but I assume that cause 
it's not an external in C).


about MIDI if I'm not wrong, bytes are grouped in accord with the type 
of message, ie Note on/off and CC are 3 bytes messages, channel pressure 
and program change are 2 bytes, sysex have variable length and so on. 
and I presume they're sent out in group.


in fact when I monitor MIDI messages coming for certain applications 
(I'm on Linux and I'm using Gmidimonitor) the console tells me the sysex 
size in bytes. so, with Pd the size is always 1 byte, but with other 
programming languages and softwares is variable and goes in accord with 
the sysex I generated.



cheers,

Mario


On 02/22/2018 09:34 PM, Alex wrote:
I haven't tested in a while but I wrote an abstraction to take a list, 
wrap 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 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-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
<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] sysex messages