Re: [PD] Good Time Stretching patches/advice?

[Derek Kwan]

On Apr 21, S.E.P. wrote:
> Hey Derek (and list)
> 
> Thanks for the clarification. I put together a test patch for your
> fgraintstr~ (tesuto.pd) and tested it with the attached .wav file (you need
> to click on the "read" message). It would seem it works without inputting
> any values into the left inlet, which is tantamount to a freeze, I
> assume...?
> 
> I'm not sure what a good grain rate is... maybe in the 20s or 30s. In
> general, it sounds a bit fuzzy and electronic and the harmonic spectrum is
> very unstable... but I'm probably doing something wrong. Any more tips?
> 

Hey, 

I've attached a patch for you to test out. It sounds fine with smaller
soundfiles, but kinda gets unstable with larger soundfiles due to the
heaviness of the abstraction...I wrote the abstraction originally for a
piece that I ported from supercollider that live-stretches a kalimba to
something like 100 times it's original length so I didn't have to use
super long soundfiles. I also had the grainrate around 5 ms so that
means grains at length 5*32  = 160 ms. Also I didn't do any
normalization in these abstractions (but in my external version I do) so
note in the test patch I've attached I multiply the outputs of the
fgrainstr abstractions by 0.25. Note that fgrainstr2 doesn't do any
transposition, but it deals better with longer sound files due to
indexing and float precision. 

If you know how to compile stuff, you can also check out my external
version that's also on my github page in the dxkpure repository. That
whole thing is sort of in a pre-release stage because I haven't figured
out the build process quite yet and my main machine runs ubuntu so I can
only provide externals built for linux so far... I've kind of moved my
efforts from making abstractions to making externals in interests of
efficiency...

Derek

=
Derek Kwan
www.derekxkwan.com
#N canvas 293 330 747 610 10;
#X obj 165 126 soundfiler;
#X obj 169 358 dac~ 1 2;
#X obj 177 62 openpanel;
#X obj 183 36 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 519 76 vsl 15 128 0.01 1 0 0 empty empty rate 0 -9 0 10 -262144
-1 -1 12700 1;
#X floatatom 508 217 5 0 0 0 - - -, f 5;
#X obj 183 326 *~ 0;
#X obj 189 228 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 571 78 vsl 15 128 -12 12 0 0 empty empty transposition 0 -9
0 10 -262144 -1 -1 6350 1;
#X floatatom 560 217 5 0 0 0 - - -, f 5;
#X msg 569 40 0;
#X msg 512 36 1;
#X obj 533 13 loadbang;
#X obj 329 26 loadbang;
#X obj 83 227 table test1;
#N canvas 1 59 912 532 phreadabstract 0;
#X obj 336 28 inlet;
#X obj 467 28 inlet;
#X obj 336 50 t b f;
#X obj 242 126 samplerate~;
#X obj 296 187 /;
#X obj 293 297 phasor~;
#X obj 296 228 * 1;
#X obj 350 172 t b f;
#X obj 293 341 outlet~;
#X text 385 28 sample size;
#X text 508 27 rate;
#X text 34 17 PHASREAD~: sample indexer abstraction;
#X obj 577 31 inlet;
#X text 614 32 phase;
#X text 30 75 in1: sample size;
#X text 28 94 in2: rate;
#X text 29 114 in3: phase;
#X text 28 154 DEREK KWAN \, 2016;
#X text 36 35 using phasor~;
#X obj 293 319 *~ 1;
#X connect 0 0 2 0;
#X connect 1 0 7 0;
#X connect 2 0 3 0;
#X connect 2 1 4 1;
#X connect 2 1 19 1;
#X connect 3 0 4 0;
#X connect 4 0 6 0;
#X connect 5 0 19 0;
#X connect 6 0 5 0;
#X connect 7 0 6 0;
#X connect 7 1 6 1;
#X connect 12 0 5 1;
#X connect 19 0 8 0;
#X restore 205 190 pd phreadabstract;
#X obj 172 244 fgrainstr2~ test1 10;
#X obj 347 247 fgrainstr~ test1 10;
#X text 393 223 SOUND ON/OFF;
#X obj 325 309 *~ 0;
#X obj 377 225 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X text 214 225 SOUND ON/OFF;
#X msg 158 91 read -resize -maxsize 4e+06 \$1 test1;
#X obj 151 292 *~ 0.25;
#X obj 363 274 *~ 0.25;
#X text 48 26 Derek Kwan \, 2016;
#X text 47 42 fgrainstrtest;
#X connect 0 0 15 0;
#X connect 2 0 22 0;
#X connect 3 0 2 0;
#X connect 4 0 5 0;
#X connect 4 0 15 1;
#X connect 6 0 1 0;
#X connect 6 0 1 1;
#X connect 7 0 6 1;
#X connect 8 0 9 0;
#X connect 8 0 17 2;
#X connect 10 0 8 0;
#X connect 11 0 4 0;
#X connect 12 0 11 0;
#X connect 12 0 10 0;
#X connect 13 0 11 0;
#X connect 15 0 16 0;
#X connect 15 0 17 0;
#X connect 16 0 23 0;
#X connect 17 0 24 0;
#X connect 19 0 1 0;
#X connect 19 0 1 1;
#X connect 20 0 19 1;
#X connect 22 0 0 0;
#X connect 23 0 6 0;
#X connect 24 0 19 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] time travelling with AKM320 and Pd

[Jaime Oliver]

> Looking at the acconnect code as well as the Pd diff that got rid of the 
> autoconnect code, it looks like it's 
> pretty easy to list i/o port info.

yes, all of the commands work fine except "aconnect -l”. At least it didn’t the 
last time I tried which is when I gave up. I am away from my linux machine 
right now, but I can try tomorrow.

> > I however, don’t know either if this is an issue for anybody else…
> 
> It'd be helpful to know whether it's a general issue or not. 
I agree…

J




> If it is a general issue then Pd will almost 
> certainly inherit those problems if I add the functionality I want.  aconnect 
> is about as simple a wrapper 
> around alsa's API as you can get.
> 
> (> and !>) best,
> J
> 
> 
> 
> > On Apr 21, 2016, at 11:09 AM, Miller Puckette  > > wrote:
> > 
> > I don't know of any reason this can't be done.  The main alsa api limitation
> > that has stopped me is: Not Worth the Hassle.  That, however, is subjective 
> > -
> > if you indeed want to attack it I'll be glad to see it (and perhaps even
> > borrow it into vanilla if you're game).
> > 
> > cheers
> > Miller
> > On Thu, Apr 21, 2016 at 02:25:26PM +, Jonathan Wilkes via Pd-list wrote:
> >> 
> >>On Thursday, April 21, 2016 3:39 AM, IOhannes m zmoelnig 
> >> mailto:zmoel...@iem.at>> wrote:
> >> 
> >> 
> >> On 2016-04-21 06:38, Jonathan Wilkes via Pd-list wrote:
>  Why can't alsa midi report "connectable" devices inside Pd, to 
>  be displayed in a dropdown?
> >> 
> >>> because nobody has implemeted it.
> >> 
> >> I'm mainly fishing for any potential alsa api limitations that would make 
> >> doing what I want very difficult or impossible.  Like "it garbles the 
> >> device 
> >> names", or "crashes every Tuesday", etc.
> >> -Jonathan
> >> 
> > 
> >> ___
> >> 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

[PD] b4p - Modular synthesizer for Pure Data

[Jose FuzzNo]

Hi,

I've been working on a library of abstractions that behaves like a modular
synthesizer. It has all the usual modules: VCO, VCA, ADSR, VCF...

If anyone knows the BEAP library for max/msp this will be familiar. It is
the same idea made with PD. All modules work with audio signals from -5 to
5 "volts". Control signals are usually from 0 to 5 "volts". As in modular
synthesizers, control signals can be used to make sound and biceversa.

I used pd-l2ork so I would recommend this package. The externals I used are
basically mrpeach and moonlib. The state saving is made with [preset_hub]
and [preset_node] from pd-l2ork.

You can download it on this link:
https://github.com/JoseFuzzNo/b4p

There is a couple of examples in the "examples" folder.

Also, as all the object names begin with "b4p_" you can import the library
at startup without any name collision.

Any feedback will be appreciated.

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

Re: [PD] time travelling with AKM320 and Pd

[Jonathan Wilkes via Pd-list]

> On Thursday, April 21, 2016 1:17 PM, Jaime Oliver 
 wrote:
 
> I should say that while aconnect works fine mostly, there are a lot of issues 
> with running it. The main one is that it doesn’t seem to show current 
> connections, just available devices, also, often it will stop working (with 
> no apparent reason) and the device needs to be unplugged and plugged in 
> again. 
I don’t know if connecting from Pd would solve these issues, but that would be 
a reason to bother. 

Looking at the acconnect code as well as the Pd diff that got rid of the 
autoconnect code, it looks like it's 
pretty easy to list i/o port info.



> I however, don’t know either if this is an issue for anybody else…
It'd be helpful to know whether it's a general issue or not.  If it is a 
general issue then Pd will almost 
certainly inherit those problems if I add the functionality I want.  aconnect 
is about as simple a wrapper 
around alsa's API as you can get.

(> and !>) best,
J



> On Apr 21, 2016, at 11:09 AM, Miller Puckette  wrote:
> 
> I don't know of any reason this can't be done.  The main alsa api limitation
> that has stopped me is: Not Worth the Hassle.  That, however, is subjective -
> if you indeed want to attack it I'll be glad to see it (and perhaps even
> borrow it into vanilla if you're game).
> 
> cheers
> Miller
> On Thu, Apr 21, 2016 at 02:25:26PM +, Jonathan Wilkes via Pd-list wrote:
>> 
>>    On Thursday, April 21, 2016 3:39 AM, IOhannes m zmoelnig 
>> wrote:
>> 
>> 
>> On 2016-04-21 06:38, Jonathan Wilkes via Pd-list wrote:
 Why can't alsa midi report "connectable" devices inside Pd, to 
 be displayed in a dropdown?
>> 
>>> because nobody has implemeted it.
>> 
>> I'm mainly fishing for any potential alsa api limitations that would make 
>> doing what I want very difficult or impossible.  Like "it garbles the device 
>> names", or "crashes every Tuesday", etc.
>> -Jonathan
>> 
> 
>> ___
>> 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] time travelling with AKM320 and Pd

[Jaime Oliver]

I should say that while aconnect works fine mostly, there are a lot of issues 
with running it. The main one is that it doesn’t seem to show current 
connections, just available devices, also, often it will stop working (with no 
apparent reason) and the device needs to be unplugged and plugged in again. 
I don’t know if connecting from Pd would solve these issues, but that would be 
a reason to bother. 
I however, don’t know either if this is an issue for anybody else…
best,
J



> On Apr 21, 2016, at 11:09 AM, Miller Puckette  wrote:
> 
> I don't know of any reason this can't be done.  The main alsa api limitation
> that has stopped me is: Not Worth the Hassle.  That, however, is subjective -
> if you indeed want to attack it I'll be glad to see it (and perhaps even
> borrow it into vanilla if you're game).
> 
> cheers
> Miller
> On Thu, Apr 21, 2016 at 02:25:26PM +, Jonathan Wilkes via Pd-list wrote:
>> 
>>On Thursday, April 21, 2016 3:39 AM, IOhannes m zmoelnig 
>>  wrote:
>> 
>> 
>> On 2016-04-21 06:38, Jonathan Wilkes via Pd-list wrote:
 Why can't alsa midi report "connectable" devices inside Pd, to 
 be displayed in a dropdown?
>> 
>>> because nobody has implemeted it.
>> 
>> I'm mainly fishing for any potential alsa api limitations that would make 
>> doing what I want very difficult or impossible.  Like "it garbles the device 
>> names", or "crashes every Tuesday", etc.
>> -Jonathan
>> 
> 
>> ___
>> 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] compiling vanilla patches as objects (gen~?)

[Jose FuzzNo]

+1
I'm currently making a library that uses a lot of cpu. I'm trying to
optimize all abstractions with [switch~] whenever possible, but a [gen~]
object would be a huge improvement.

2016-04-21 18:17 GMT+02:00 Alexandre Torres Porres :

> howdy, wtih things like the heavy compiler, the libpd and stuff, how crazy
> would it be to expect something like an object compiler to host pd patches
> in pd?
>
> I think that'd be something like gen~ in max/msp.
>
> cheers
>
> ___
> 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] compiling vanilla patches as objects (gen~?)

[Alexandre Torres Porres]

howdy, wtih things like the heavy compiler, the libpd and stuff, how crazy
would it be to expect something like an object compiler to host pd patches
in pd?

I think that'd be something like gen~ in max/msp.

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

Re: [PD] time travelling with AKM320 and Pd

[Dan Wilcox]

Personally, I think the ports should be listed when using ALSA *and* still have 
functionality of using aconnect. Totally possible.

I use a similar set up on OSX where I have a permanent virtual port for Pd set 
in the OSX Midi settings which I route everything to, either in the other app 
or via an aconnect-style routing app like MidiPatchbay 
.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Apr 21, 2016, at 9:44 AM, Jonathan Wilkes  wrote:
> 
> Thanks, Dan.
> 
> As for the +1's-- no greybeards will be harmed in my work to improve the 
> interface.
> 
> -Jonathan
> 
> 
> On Thursday, April 21, 2016 11:36 AM, Dan Wilcox  wrote:
> 
> 
> If Pd uses Portmidi  on Linux, 
> then it should be pretty easy to list the available ports. It’s no so hard 
> with ALSA itself either. Check the RtMidi 
>  ALSA implementation inside 
> RtMidi.cpp. I’ve used that in the past as a reference, although it’s a little 
> hairy to pick apart, it’s at least a good working example beyond the ALSA 
> documentation.
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
>> On Apr 21, 2016, at 9:28 AM, pd-list-requ...@lists.iem.at 
>>  wrote:
>> 
>> From: Miller Puckette mailto:m...@ucsd.edu>>
>> Subject: Re: [PD] time travelling with AKM320 and Pd
>> Date: April 21, 2016 at 9:09:58 AM MDT
>> To: Jonathan Wilkes mailto:jancs...@yahoo.com>>
>> Cc: "pd-list@lists.iem.at " 
>> mailto:pd-list@lists.iem.at>>, IOhannes m zmoelnig 
>> mailto:zmoel...@iem.at>>
>> 
>> 
>> I don't know of any reason this can't be done.  The main alsa api limitation
>> that has stopped me is: Not Worth the Hassle.  That, however, is subjective -
>> if you indeed want to attack it I'll be glad to see it (and perhaps even
>> borrow it into vanilla if you're game).
> 
> 
> 

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

Re: [PD] time travelling with AKM320 and Pd

[Jonathan Wilkes via Pd-list]

Thanks, Dan.
As for the +1's-- no greybeards will be harmed in my work to improve the 
interface.
-Jonathan
 

On Thursday, April 21, 2016 11:36 AM, Dan Wilcox  
wrote:
 

 If Pd uses Portmidi on Linux, then it should be pretty easy to list the 
available ports. It’s no so hard with ALSA itself either. Check the RtMidi ALSA 
implementation inside RtMidi.cpp. I’ve used that in the past as a reference, 
although it’s a little hairy to pick apart, it’s at least a good working 
example beyond the ALSA documentation.

Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com

On Apr 21, 2016, at 9:28 AM, pd-list-requ...@lists.iem.at wrote:
From: Miller Puckette 
Subject: Re: [PD] time travelling with AKM320 and Pd
Date: April 21, 2016 at 9:09:58 AM MDT
To: Jonathan Wilkes 
Cc: "pd-list@lists.iem.at" , IOhannes m zmoelnig 



I don't know of any reason this can't be done.  The main alsa api limitation
that has stopped me is: Not Worth the Hassle.  That, however, is subjective -
if you indeed want to attack it I'll be glad to see it (and perhaps even
borrow it into vanilla if you're game).



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

Re: [PD] time travelling with AKM320 and Pd

[Dan Wilcox]

If Pd uses Portmidi  on Linux, then 
it should be pretty easy to list the available ports. It’s no so hard with ALSA 
itself either. Check the RtMidi  ALSA 
implementation inside RtMidi.cpp. I’ve used that in the past as a reference, 
although it’s a little hairy to pick apart, it’s at least a good working 
example beyond the ALSA documentation.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Apr 21, 2016, at 9:28 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Miller Puckette mailto:m...@ucsd.edu>>
> Subject: Re: [PD] time travelling with AKM320 and Pd
> Date: April 21, 2016 at 9:09:58 AM MDT
> To: Jonathan Wilkes mailto:jancs...@yahoo.com>>
> Cc: "pd-list@lists.iem.at " 
> mailto:pd-list@lists.iem.at>>, IOhannes m zmoelnig 
> mailto:zmoel...@iem.at>>
> 
> 
> I don't know of any reason this can't be done.  The main alsa api limitation
> that has stopped me is: Not Worth the Hassle.  That, however, is subjective -
> if you indeed want to attack it I'll be glad to see it (and perhaps even
> borrow it into vanilla if you're game).

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

Re: [PD] time travelling with AKM320 and Pd

[Dan Wilcox]

+1 here as well.

On Linux, I use a script which calls aconnect after pd starts to make 
connections by name. I also have a udev rule to autoconnect things once they 
are plugged in.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Apr 21, 2016, at 4:00 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Lorenzo Sutton  >
> Subject: Re: [PD] time travelling with AKM320 and Pd
> Date: April 21, 2016 at 3:15:37 AM MDT
> To: pd-list@lists.iem.at 
> 
> 
> 
> 
> On 21/04/2016 09:36, IOhannes m zmoelnig wrote:
>> On 2016-04-21 06:38, Jonathan Wilkes via Pd-list wrote:
>>> Why can't alsa midi report "connectable" devices inside Pd, to
>>> be displayed in a dropdown?
>> 
>> because nobody has implemeted it.
>> 
>> personally i find that it preferable to use a specialised software for
>> the patching¹.
> 
> +1

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

Re: [PD] [pure-data:pure-data] 9 new commits to pure-data

[Miller Puckette]

Hmm, trying to get my mailer to reply to list without replying to Iohannes
too...

On Thu, Apr 21, 2016 at 08:21:09AM -0700, Miller Puckette wrote:
> Thanks - I'm still trying to crawl through all the patches and bug reports
> (particularly on the Pd mailing list but also elsewhere) - this one is a
> no-brainer so I just went and applied it.
> 
> thanks
> Miller
> 
> On Thu, Apr 21, 2016 at 04:54:14PM +0200, IOhannes m zmölnig wrote:
> > hi miller,
> > 
> > it seems that the Pd-0.47 release is drawing nearer.
> > great!
> > 
> > however,...
> > 
> > On 04/21/2016 04:34 PM, Pure Data Computer Music System Git repository
> > wrote:
> > > Makefile.am gets new list of doc 
> > > files
> > > 
> > > By Miller Puckette on 04/21/2016 04:13
> > > [**View 
> > > Changes**](https://sourceforge.net/p/pure-data/pure-data/ci/298ba37f9be4b9fc7e8501dd30408ffd82582a5d/)
> > 
> > this seems to have introduced a slight syntax error (a line-continuation
> > "\" followed by a non-continuing line)
> > 
> > the attached patch fixes this (by removing the stray backslash).
> > 
> > thanks
> > 
> > gfamrds
> > IOhannes
> 
> > From c5c54366be60c12dfa80d49b012d3fc36a8b6969 Mon Sep 17 00:00:00 2001
> > From: IOhannes m zmoelnig 
> > Date: Thu, 21 Apr 2016 16:50:44 +0200
> > Subject: [PATCH] fixed syntax-error in Makefile.am
> > 
> > ---
> >  Makefile.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index bc9c49d..1c664ca 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -476,5 +476,5 @@ nobase_dist_libpd_DATA = \
> >   doc/7.stuff/tools/testtone.pd \
> >   doc/sound/bell.aiff \
> >   doc/sound/voice2.wav \
> > - doc/sound/voice.wav \
> > + doc/sound/voice.wav
> >  
> > -- 
> > 2.8.0.rc3
> > 
> 
> 
> 
> 

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

Re: [PD] time travelling with AKM320 and Pd

[Miller Puckette]

I don't know of any reason this can't be done.  The main alsa api limitation
that has stopped me is: Not Worth the Hassle.  That, however, is subjective -
if you indeed want to attack it I'll be glad to see it (and perhaps even
borrow it into vanilla if you're game).

cheers
Miller
On Thu, Apr 21, 2016 at 02:25:26PM +, Jonathan Wilkes via Pd-list wrote:
>  
> On Thursday, April 21, 2016 3:39 AM, IOhannes m zmoelnig 
>  wrote:
>  
> 
>  On 2016-04-21 06:38, Jonathan Wilkes via Pd-list wrote:
> >> Why can't alsa midi report "connectable" devices inside Pd, to 
> >> be displayed in a dropdown?
> 
> > because nobody has implemeted it.
> 
> I'm mainly fishing for any potential alsa api limitations that would make 
> doing what I want very difficult or impossible.  Like "it garbles the device 
> names", or "crashes every Tuesday", etc.
> -Jonathan
>   

> ___
> 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] time travelling with AKM320 and Pd

[Jonathan Wilkes via Pd-list]

 
On Thursday, April 21, 2016 3:39 AM, IOhannes m zmoelnig  
wrote:
 

 On 2016-04-21 06:38, Jonathan Wilkes via Pd-list wrote:
>> Why can't alsa midi report "connectable" devices inside Pd, to 
>> be displayed in a dropdown?

> because nobody has implemeted it.

I'm mainly fishing for any potential alsa api limitations that would make 
doing what I want very difficult or impossible.  Like "it garbles the device 
names", or "crashes every Tuesday", etc.
-Jonathan
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] time travelling with AKM320 and Pd

[Lorenzo Sutton]

On 21/04/2016 09:36, IOhannes m zmoelnig wrote:

On 2016-04-21 06:38, Jonathan Wilkes via Pd-list wrote:

Why can't alsa midi report "connectable" devices inside Pd, to
be displayed in a dropdown?


because nobody has implemeted it.

personally i find that it preferable to use a specialised software for
the patching¹.


+1

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

Re: [PD] time travelling with AKM320 and Pd

[IOhannes m zmoelnig]

On 2016-04-21 06:38, Jonathan Wilkes via Pd-list wrote:
> Why can't alsa midi report "connectable" devices inside Pd, to 
> be displayed in a dropdown?

because nobody has implemeted it.

personally i find that it preferable to use a specialised software for
the patching¹.
Pd doesn't necessarily need to poll the available MIDI devices every
know and then to discover newly connected devices. otoh, applications
like qjackctl can  (and will) do this for you, and you can easily
configure it to automatically connect your AKM320 and your UM-1 to Pd
whenever you plug them in, while reserving your BCM2000 for the use with
ardour.

i also find it preferable to be able to route multiple MIDI devices to
the same MIDI port within Pd
e.g. if I use ch#1 on my MIDI keyboard and ch#10 on my drum-sequencer,
and i want to hook both into Pd, there is little use to open up two MIDI
ports and reserve ch1-16 for the keyboard and ch17-32 for the drum
sequencer; instead i want MIDI merge functionality.
otoh, if i want to drive Pd with two independent multi-channel MIDI
sequencers, it might very well make sense to be able to separate them on
a patch level.

the alsa-midi implementation *used* to auto-connect to all available
MIDI-ports (in special circumstances). this was disabled because:
- it was unclear how to turn off this behaviour (e.g. for those who
wanted their MIDI-devices to be connected to multiple ports in Pd)
- it would also automatically connect with the MIDI-thru virtual device
that get's automatically loaded, and *this* is rather annoying. at that
time there was noobvious way to programmatically exclude the MIDI-thru
device (or e.g. any non-hardware devices), short of hardcoding their
name into a blacklist, which is not seem particularily appealing.


anyhow.
the main challenge is to make the system flexible for power-users and at
the same time allow plug-and-play setup when the flexibility is not needed.
the current implementation favours flexibility.
if someone can come-up with a scheme that allows both, we should of
course go that route.
if somebody comes up with a solution that favours plug-and-play at the
expense of flexibility, i'd like to veto.


cfg,dasdr
IOhannes




¹ fwiiw, there are even some people who very much prefer JACK audio
applications to *not* automatically connect to the "system" output - or
any other output for that matter (unfortunately this is an option that
Pd currently does not offer)



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