date:20180222

Re: [PD] Pd on Tiny Core Linux on Raspberry Pi

2018-02-22 Thread Thomas Grill

Hi Chris,

> 
>> If you want to install them in the meantime, please grab the files from 
>> http://l.g.org/puredata_tcz
>> The manual installation procedure is the following:
> I was able to do a manual install quite easily by copying the puredata.tcz 
> file over to the RPi and then running:
> 
> tce-load -i ./puredata.tcz
> 
> The reason this did not work before (which I emailed you about) was I had 
> been doing `wget http://l.g.org/puredata_tcz` not realising this was your 
> ownCloud server page rather than the package file itself.
> 
> One thing I noticed is your package seems to be mounted from a different 
> location to all of the other packages:
> 
> $ mount | tail -n 4
> /mnt/mmcblk0p2/tce/optional/libvorbis.tcz on /tmp/tcloop/libvorbis type 
> squashfs (ro,relatime)
> /mnt/mmcblk0p2/tce/optional/libogg-dev.tcz on /tmp/tcloop/libogg-dev type 
> squashfs (ro,relatime)
> /mnt/mmcblk0p2/tce/optional/libogg.tcz on /tmp/tcloop/libogg type squashfs 
> (ro,relatime)
> /dev/loop108 on /tmp/tcloop/puredata type squashfs (ro,relatime)
> 
> Note the mount source of `/dev/loop108` instead of `/mnt/mmcblk0p2...`.

The reason is that the "tce-load -i" command doesn't update the onboot.txt file 
which governs which packages are mounted at startup.
Hence the mount is temporary.

best, Thomas



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] ofelia v1.0.4: Pd external library written with openFrameworks

2018-02-22 Thread Ed Kelly via Pd-list

Hi Zack,
I too am having Pd crash when ofelia is loaded.Would it help if I compiled it 
from source?I have Ubuntu 16.04 LTS, 64 bit distro.
Thanks,Ed

_-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and published Research, go to 
http://sharktracks.co.uk  

On Thursday, 22 February 2018, 04:39:45 GMT, Zack Lee  
wrote:  
 
 Hi Jesse, Good to hear it works well on your systems.I hope you enjoy using 
the library. :)

Zack
2018-02-22 6:48 GMT+09:00 Jesse Mejia :

This is rad - thanks! On windows 10 I installed via dekken using the default 
path, and on two separate machines I needed to add the startup flag -lib ofelia
but now everything seems to be working well.
Thanks - this looks amazing! 
-jesse
On Feb 21, 2018, at 1:08 PM, Alan Brooker  wrote:


Hi Zack,
Works perfectly for me on Windows 10, this is great! Thanks so much for the 
effort in putting this library out, along with the recent  behind the scenes 
developments with Gem and the SVG capabilities in Purr Data,  Pd is again 
having some great options for graphics & visuals. 
Just curious, I'm not an OF expert (and forgive me if this is not documented 
somewhere) but is it possible to write scripts in OF and then import them into 
Pd in some way?
Thanks again

|  | Virus-free. www.avg.com  |


On Wed, Feb 21, 2018 at 5:16 PM, Alex  wrote:

Hey Zach,
I'm not on my linux machine right now so I'll have to get back to that later 
but in the mean time, on my work machine, I've run nm -u and attached what I 
got.
Clearly there is a lot more being built in to the osx version.
Last night I did actually try to install open frameworks on my linux machine 
but I had a conflict with a dependency that I didn't have time to resolve.
I might just look at the output of nm for linux and see if I can just install 
those that aren't linked there.

-Alex

On Tue, Feb 20, 2018 at 8:16 PM, Zack Lee  wrote:

Thanks for the info.I actually built the binary on the exact same distro: 
Ubuntu 16.04.3 LTS.
Could you please run the "install_dependencies.sh" script and see if it 
works?I'm sorry I don't really get what is causing the problem.I will also try 
reinstalling Ubuntu 16.04 LTS and see if it works and will let you know 
asap.Thank you.
Zack


2018-02-21 12:51 GMT+09:00 Alex :

I've also attached the gdb backtrace and the output from nm -u ofelia.l_ia64 > 
nm.txt

looks like it expects i have cairo, FreeImage, glew, and some other libs..

On Tue, Feb 20, 2018 at 7:44 PM, Alex  wrote:

no problem Zack,

alex@workin:~/local/src/openFr ameworks/scripts/linux$ lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:    16.04
Codename:    xenial

you mean the .iso for this version of ubuntu? http://releases.ubuntu.com/16. 
04/ubuntu-16.04.3-desktop-amd6 4.iso

On Tue, Feb 20, 2018 at 7:20 PM, Zack Lee  wrote:

Hi, Alex 
Thanks for the report.The similar problems have been reported by some Linux 
users.Could you please tell me which Ubuntu you're using?I would appreciate if 
you could give me a download link to the .iso image file.Thank you and I don't 
think you need to install openFrameworks as it shouldn't crash anyway.
Zack








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



___
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] [PD-announce] ofelia v1.0.4: Pd external library written with openFrameworks

2018-02-22 Thread Zack Lee

Hi, Jesse
I'm currently trying to fix the issue via cloud Linux server as I only have
Apple hardwares.
I will fix the issue and let you know as soon as possible. (within 24 hours)
Thank you!

Zack

2018-02-22 18:33 GMT+09:00 Ed Kelly :

> Hi Zack,
>
> I too am having Pd crash when ofelia is loaded.
> Would it help if I compiled it from source?
> I have Ubuntu 16.04 LTS, 64 bit distro.
>
> Thanks,
> Ed
>
> _-_-_-_-_-_-_-^-_-_-_-_-_-_-_
>
> For *Lone Shark *releases, *Pure Data *software and published *Research*,
> go to http://sharktracks.co.uk
>
>
> On Thursday, 22 February 2018, 04:39:45 GMT, Zack Lee 
> wrote:
>
>
> Hi Jesse, Good to hear it works well on your systems.
> I hope you enjoy using the library. :)
>
> Zack
>
> 2018-02-22 6:48 GMT+09:00 Jesse Mejia :
>
> This is rad - thanks! On windows 10 I installed via dekken using the
> default path, and on two separate machines I needed to add the startup flag
> -lib ofelia
>
> but now everything seems to be working well.
>
> Thanks - this looks amazing!
>
> -jesse
>
> On Feb 21, 2018, at 1:08 PM, Alan Brooker 
> wrote:
>
> Hi Zack,
>
> Works perfectly for me on Windows 10, this is great! Thanks so much for
> the effort in putting this library out, along with the recent  behind the
> scenes developments with Gem and the SVG capabilities in Purr Data,  Pd is
> again having some great options for graphics & visuals.
>
> Just curious, I'm not an OF expert (and forgive me if this is not
> documented somewhere) but is it possible to write scripts in OF and then
> import them into Pd in some way?
>
> Thanks again
>
>
> 
>  Virus-free.
> www.avg.com
> 
> <#m_-7287048229375114008_m_-4611287119169657742_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, Feb 21, 2018 at 5:16 PM, Alex  wrote:
>
> Hey Zach,
> I'm not on my linux machine right now so I'll have to get back to that
> later but in the mean time, on my work machine, I've run nm -u and attached
> what I got.
> Clearly there is a lot more being built in to the osx version.
> Last night I did actually try to install open frameworks on my linux
> machine but I had a conflict with a dependency that I didn't have time to
> resolve.
> I might just look at the output of nm for linux and see if I can just
> install those that aren't linked there.
>
> -Alex
>
> On Tue, Feb 20, 2018 at 8:16 PM, Zack Lee  wrote:
>
> Thanks for the info.
> I actually built the binary on the exact same distro: Ubuntu 16.04.3 LTS.
>
> Could you please run the "install_dependencies.sh" script and see if it
> works?
> I'm sorry I don't really get what is causing the problem.
> I will also try reinstalling Ubuntu 16.04 LTS and see if it works and will
> let you know asap.
> Thank you.
>
> Zack
>
>
>
> 2018-02-21 12:51 GMT+09:00 Alex :
>
> I've also attached the gdb backtrace and the output from nm -u
> ofelia.l_ia64 > nm.txt
>
> looks like it expects i have cairo, FreeImage, glew, and some other libs..
>
> On Tue, Feb 20, 2018 at 7:44 PM, Alex  wrote:
>
> no problem Zack,
>
> alex@workin:~/local/src/openFr ameworks/scripts/linux$ lsb_release -a
> No LSB modules are available.
> Distributor ID:Ubuntu
> Description:Ubuntu 16.04.3 LTS
> Release:16.04
> Codename:xenial
>
> you mean the .iso for this version of ubuntu? http://releases.ubuntu.com/16.
> 04/ubuntu-16.04.3-desktop-amd6 4.iso
> 
>
> On Tue, Feb 20, 2018 at 7:20 PM, Zack Lee  wrote:
>
> Hi, Alex
>
> Thanks for the report.
> The similar problems have been reported by some Linux users.
> Could you please tell me which Ubuntu you're using?
> I would appreciate if you could give me a download link to the .iso image
> file.
> Thank you and I don't think you need to install openFrameworks as it
> shouldn't crash anyway.
>
> Zack
>
>
>
>
>
>
> __ _
> 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 
>
>
> ___
> 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] [PD-announce] ofelia v1.0.4: Pd external library written with openFrameworks

2018-02-22 Thread Zack Lee

I meant Ed and not Jesse..
Sorry about that. :)

Zack

2018-02-22 18:57 GMT+09:00 Zack Lee :

> Hi, Jesse
> I'm currently trying to fix the issue via cloud Linux server as I only
> have Apple hardwares.
> I will fix the issue and let you know as soon as possible. (within 24
> hours)
> Thank you!
>
> Zack
>
> 2018-02-22 18:33 GMT+09:00 Ed Kelly :
>
>> Hi Zack,
>>
>> I too am having Pd crash when ofelia is loaded.
>> Would it help if I compiled it from source?
>> I have Ubuntu 16.04 LTS, 64 bit distro.
>>
>> Thanks,
>> Ed
>>
>> _-_-_-_-_-_-_-^-_-_-_-_-_-_-_
>>
>> For *Lone Shark *releases, *Pure Data *software and published *Research*,
>> go to http://sharktracks.co.uk
>>
>>
>> On Thursday, 22 February 2018, 04:39:45 GMT, Zack Lee 
>> wrote:
>>
>>
>> Hi Jesse, Good to hear it works well on your systems.
>> I hope you enjoy using the library. :)
>>
>> Zack
>>
>> 2018-02-22 6:48 GMT+09:00 Jesse Mejia :
>>
>> This is rad - thanks! On windows 10 I installed via dekken using the
>> default path, and on two separate machines I needed to add the startup flag
>> -lib ofelia
>>
>> but now everything seems to be working well.
>>
>> Thanks - this looks amazing!
>>
>> -jesse
>>
>> On Feb 21, 2018, at 1:08 PM, Alan Brooker 
>> wrote:
>>
>> Hi Zack,
>>
>> Works perfectly for me on Windows 10, this is great! Thanks so much for
>> the effort in putting this library out, along with the recent  behind the
>> scenes developments with Gem and the SVG capabilities in Purr Data,  Pd is
>> again having some great options for graphics & visuals.
>>
>> Just curious, I'm not an OF expert (and forgive me if this is not
>> documented somewhere) but is it possible to write scripts in OF and then
>> import them into Pd in some way?
>>
>> Thanks again
>>
>>
>> 
>>  Virus-free.
>> www.avg.com
>> 
>> <#m_-5995149351277459690_m_-7287048229375114008_m_-4611287119169657742_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Wed, Feb 21, 2018 at 5:16 PM, Alex  wrote:
>>
>> Hey Zach,
>> I'm not on my linux machine right now so I'll have to get back to that
>> later but in the mean time, on my work machine, I've run nm -u and attached
>> what I got.
>> Clearly there is a lot more being built in to the osx version.
>> Last night I did actually try to install open frameworks on my linux
>> machine but I had a conflict with a dependency that I didn't have time to
>> resolve.
>> I might just look at the output of nm for linux and see if I can just
>> install those that aren't linked there.
>>
>> -Alex
>>
>> On Tue, Feb 20, 2018 at 8:16 PM, Zack Lee  wrote:
>>
>> Thanks for the info.
>> I actually built the binary on the exact same distro: Ubuntu 16.04.3 LTS.
>>
>> Could you please run the "install_dependencies.sh" script and see if it
>> works?
>> I'm sorry I don't really get what is causing the problem.
>> I will also try reinstalling Ubuntu 16.04 LTS and see if it works and
>> will let you know asap.
>> Thank you.
>>
>> Zack
>>
>>
>>
>> 2018-02-21 12:51 GMT+09:00 Alex :
>>
>> I've also attached the gdb backtrace and the output from nm -u
>> ofelia.l_ia64 > nm.txt
>>
>> looks like it expects i have cairo, FreeImage, glew, and some other libs..
>>
>> On Tue, Feb 20, 2018 at 7:44 PM, Alex  wrote:
>>
>> no problem Zack,
>>
>> alex@workin:~/local/src/openFr ameworks/scripts/linux$ lsb_release -a
>> No LSB modules are available.
>> Distributor ID:Ubuntu
>> Description:Ubuntu 16.04.3 LTS
>> Release:16.04
>> Codename:xenial
>>
>> you mean the .iso for this version of ubuntu? http://releases.ubuntu.com/16.
>> 04/ubuntu-16.04.3-desktop-amd6 4.iso
>> 
>>
>> On Tue, Feb 20, 2018 at 7:20 PM, Zack Lee  wrote:
>>
>> Hi, Alex
>>
>> Thanks for the report.
>> The similar problems have been reported by some Linux users.
>> Could you please tell me which Ubuntu you're using?
>> I would appreciate if you could give me a download link to the .iso image
>> file.
>> Thank you and I don't think you need to install openFrameworks as it
>> shouldn't crash anyway.
>>
>> Zack
>>
>>
>>
>>
>>
>>
>> __ _
>> 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 
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>
>
___
Pd-

Re: [PD] [PD-announce] Cyclone 0.3 beta 3 released!

2018-02-22 Thread Alexandre Torres Porres

2018-02-21 17:35 GMT-03:00 Alexandre Torres Porres :
>
>
> Only missing Linux 32 bits right now
>

Not anymore, everything is up already on https://github.com/
porres/pd-cyclone/releases/tag/cyclone0.3beta-3

but we're facing technical difficulties uploading to deken :/ - a report
was done at https://github.com/pure-data/deken/issues/178

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

Re: [PD] [PD-announce] ofelia v1.0.4: Pd external library written, with openFrameworks (Zack Lee)

2018-02-22 Thread Jim Ruxton

Thank you for this External. Some great objects in there.  I am using 
Ubuntu 17.10 . It appeared to install perfectly and I ran the script to 
install dependencies. The non graphics objects I have tested are working 
great but I don't get anything rendered to the Ofelia window when I try 
out the graphics examples.


Jim


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

Re: [PD] [PD-dev] Fwd: external help, please

2018-02-22 Thread Miller Puckette

Check that the input addresses are different from the output ones - usually
in a case like that Pd will re-use the memory from the inputs for the outputs,
so your object needs to be able to operate in-place.

(hint: allocate a bunch of temporary signals on teh stack using alloca(), and
put the outputs in them irst; then when you're through using the intputs for
anything, you can copy the temporary outputs to the real ones.)

cheers
Miller

On Thu, Feb 22, 2018 at 02:38:24PM -0300, Alexandre Torres Porres wrote:
> Hi folks, I need help on an external. I wanna perform a task on an array of
> signal inputs. It's a multichannel object, and I define the number of
> channels with an argument.
> 
> Here's just the core of it, as an object named "mtx~", where I map the
> input to the output. And this is what happens.
> 
> [image: Imagem inline 1]
> 
> So you see I get a weird mirrored output, instead of something like "1 2 3
> 4 5 6".
> 
> The perform method in the code is just
> 
> static t_int *mtx_perform(t_int *w){
> 
> t_mtx *x = (t_mtx *)(w[1]);
> 
> int nblock = (int)(w[2]);
> 
> t_float **in_vectors = x->x_in_vectors;
> 
> t_float **out_vectors = x->x_out_vectors;
> 
> t_int i;
> 
> for(i = 0; i < x->x_ch; i++){
> 
> t_float *in = in_vectors[i];
> 
> t_float *out = out_vectors[i];
> 
> t_int n = nblock;
> 
> while(n--)
> 
> *out++ = *in++;
> 
> }
> 
> return (w + 3);
> 
> }
> 
> What am I doing wrong? How should this go? See attached the help test
> example and code.
> 
> Thanks






> #include "m_pd.h"
> 
> typedef struct  _mtx{
>   t_objectx_obj;
> t_int   x_ch;
> t_float   **x_in_vectors;
> t_float   **x_out_vectors;
> }t_mtx;
> 
> static t_class *mtx_class;
> 
> static t_int *mtx_perform(t_int *w){
> t_mtx *x = (t_mtx *)(w[1]);
> int nblock = (int)(w[2]);
> t_float **in_vectors = x->x_in_vectors;
> t_float **out_vectors = x->x_out_vectors;
> t_int i;
> for(i = 0; i < x->x_ch; i++){
> t_float *in = in_vectors[i];
> t_float *out = out_vectors[i];
> t_int n = nblock;
> while(n--)
> *out++ = *in++;
> }
> return (w + 3);
> }
> 
> static void mtx_dsp(t_mtx *x, t_signal **sp){
> t_int i, nblock = sp[0]->s_n;
> t_signal **sigp = sp;
> t_float **vecp = x->x_in_vectors;
> for(i = 0; i < x->x_ch; i++)
>   *vecp++ = (*sigp++)->s_vec; // input vectors
> vecp = x->x_out_vectors;
> for(i = 0; i < x->x_ch; i++)
>   *vecp++ = (*sigp++)->s_vec; // output vectors
> dsp_add(mtx_perform, 2, x, nblock);
> }
> 
> static void *mtx_free(t_mtx *x){
> freebytes(x->x_in_vectors, x->x_ch * sizeof(*x->x_in_vectors));
> freebytes(x->x_out_vectors, x->x_ch * sizeof(*x->x_out_vectors));
>   return(void *)x;
> }
> 
> static void *mtx_new(t_floatarg f){
>   t_mtx *x = (t_mtx *)pd_new(mtx_class);
> x->x_ch = (int)f < 1 ? 1 : (int)f > 64 ? 64 : (int)f;
>   x->x_in_vectors = getbytes(x->x_ch * sizeof(*x->x_in_vectors));
> x->x_out_vectors = getbytes(x->x_ch * sizeof(*x->x_out_vectors));
> t_int i;
> for(i = 0; i < x->x_ch; i++)
> inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_signal, &s_signal);
>   for(i = 0; i < x->x_ch; i++)
>   outlet_new(&x->x_obj, gensym("signal"));
>   return(x);
> }
> 
> void mtx_tilde_setup(void){
> mtx_class = class_new(gensym("mtx~"), (t_newmethod)mtx_new, 
> (t_method)mtx_free,
>sizeof(t_mtx), CLASS_NOINLET, A_DEFFLOAT, 0);
> class_addmethod(mtx_class, (t_method)mtx_dsp, gensym("dsp"), A_CANT, 0);
> }

> ___
> Pd-dev mailing list
> pd-...@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev


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

[PD] Fwd: [Faudiostream-users] IFC-18: 2nd Call for Papers - International Faust Conference - Deadline Extended!

2018-02-22 Thread Albert Graef

[Apologies for cross posting, please circulate widely.]

*New submission deadline: March 26, 2018*
1st International Faust Conference - Johannes Gutenberg University, Mainz
(Germany), July 17-18, 2018

The International Faust Conference (IFC-18: http://www.ifc18.uni-mainz.de)
will take place at the Johannes Gutenberg University
 of Mainz (Germany) on July 17-18, 2018. It aims
at gathering developers and users of the Faust programming language
 to present current projects and discuss future
directions for Faust and its community.

Participants will be able to share their work through paper presentations.
A series of round tables on various topics will serve as a platform to
brainstorm on Faust's features, semantics, tools, applications, etc. to
determine future directions for this language. Open spaces for demos and
workshops will be available for participants to openly share their ongoing
projects with the rest of the community.

As a special event, the winner of GRAME's Faust Open-Source Software
Competition will be announced during IFC-18.

IFC-18 is free and everyone is welcome to attend!

*Call for Papers*

We welcome submissions from academic, professional, independent
programmers, artists, etc. We solicit original papers centered around the Faust
programming language  in the following categories:

   - Original research
   - Technology tutorial
   - Artistic project report (e.g., installation, composition, etc.)

Paper should be up to 14 pages in length, non anonymous, and formatted
according to this template
. *Submissions
should be carried out via our EasyChair portal
*.

All submissions are subject to peer review. Acceptance may be conditional
upon changes being made to the paper as directed by reviewers.

Accepted papers will be published on-line as well as in the IFC-18
proceedings paper version. They will be presented by their author(s) at
IFC-18 as 15 minutes presentations (+ 5 minutes for questions).

Feel free to contact us if you have any question.

*Important Dates*

   - Papers submission deadline: March 26, 2018  March 2, 2018
   - Notification of Acceptance: May 5, 2018 May 1, 2018
   - Camera-Ready Version: June 1, 2018

*Call for Round Table Topics*

A series of round tables on the following themes will take place both
afternoons of IFC-18:

   - Faust Tools (e.g., Architectures, IDE, Faust Code Generator, On-Line
   Services, etc.)
   - DSP in Faust and Faust Libraries (e.g., New Algorithms, New Libraries,
   Missing Functions, etc.)
   - Faust Compiler and Semantics
   - Other Topics/Open Session

We solicit topic suggestions from the Faust community for each of these
themes. Topics can be submitted by means of this Google form
. They will be introduced during
the round tables by the session chair.

*Contact*
Please, address your questions to: if...@muwiinfa.geschichte.uni-mainz.de
Conference website: http://www.ifc18.uni-mainz.de

-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggr...@gmail.com
WWW:https://plus.google.com/+AlbertGraef
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] sysex messages

2018-02-22 Thread mario buoninfante


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

2018-02-22 Thread Alex

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

Re: [PD] sysex messages

2018-02-22 Thread mario buoninfante


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





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

Re: [PD] sysex messages

2018-02-22 Thread Alex

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

Re: [PD] sysex messages

2018-02-22 Thread mario buoninfante

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


midi is a byte oriented protocol..

On Thu, Feb 22, 2018 at 1:24 PM, mario buoninfante
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








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

Re: [PD] sysex messages

2018-02-22 Thread Ryan Smith

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

2018-02-22 Thread mario buoninfante


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

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"
An: Alex
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
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
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

2018-02-22 Thread mario buoninfante

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"
An: Alex
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 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:

On Thu, Feb 22, 2018 at 1:24 PM, mario buoninfante 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

2018-02-22 Thread Christof Ressi

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" 
> An: "Christof Ressi" , pd-list 
> 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" 
> > An: Alex 
> > 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 
> > 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 
> > 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

2018-02-22 Thread mario buoninfante

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" 
An: Alex 
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 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 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

2018-02-22 Thread mario buoninfante

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:

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"
An: "Christof Ressi" , pd-list
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:

Gesendet: Donnerstag, 22. Februar 2018 um 23:05 Uhr
Von: "mario buoninfante"
An: Alex
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 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 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

2018-02-22 Thread Alex

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

Re: [PD] sysex messages

2018-02-22 Thread mario buoninfante

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:

Gesendet: Donnerstag, 22. Februar 2018 um 23:31 Uhr
Von: "mario buoninfante"
An: "Christof Ressi" , pd-list
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:

Gesendet: Donnerstag, 22. Februar 2018 um 23:05 Uhr
Von: "mario buoninfante"
An: Alex
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 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 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

2018-02-22 Thread mario buoninfante

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 
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" mailto:mario.buoninfa...@gmail.com>>
An: Alex mailto: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
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]


  midi is a byte oriented protocol..
  On Thu, Feb 22, 2018 at 1:24 PM, mario buoninfante
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
] mailing list
UNSUBSCRIBE and account-management ->

https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]

Re: [PD] sysex messages

2018-02-22 Thread Marco Hugo Schretter


hi mario,

for me the following works without issues from every point
to every point with sysex-to-midi-to-osc-to-midi-to-sysex
from every point in the line to every point with pd-vanilla
(bcf<->yamaha_dm2000<->osc<->hammerfall<->ableton)

parse your desired message in the other way round (so
that the end-msg is the first and start-msg ist last)
and use the right-to-left handling of the unpack object
for the output to the midiout in the right order:

example (volume-fader-ctl):
dm2000 sysex has 14 values
so when i talk to dm2000 i say



[1 69 1(<-- this example sets ch1-volume for hi+lo-bits
|
[247 $2 $3 0 0 $1 0 28 1 127 62 16 67 240(
|
unpack 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|/
_
midiout

===

check the right order of sysex after unpack with print

liebe grüße
marco

Am 22.02.18 um 23:38 schrieb mario buoninfante:

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" 
An: "Christof Ressi" , pd-list 
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" 
An: Alex 
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 
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 
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:/

Re: [PD] Pd on Tiny Core Linux on Raspberry Pi

Re: [PD] [PD-announce] ofelia v1.0.4: Pd external library written with openFrameworks

Re: [PD] [PD-announce] ofelia v1.0.4: Pd external library written with openFrameworks

Re: [PD] [PD-announce] ofelia v1.0.4: Pd external library written with openFrameworks

Re: [PD] [PD-announce] Cyclone 0.3 beta 3 released!

Re: [PD] [PD-announce] ofelia v1.0.4: Pd external library written, with openFrameworks (Zack Lee)

Re: [PD] [PD-dev] Fwd: external help, please

[PD] Fwd: [Faudiostream-users] IFC-18: 2nd Call for Papers - International Faust Conference - Deadline Extended!

[PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

Re: [PD] sysex messages

24 matches

Site Navigation

Mail list logo

Footer information