Re: [PD] Cross-platform uniform GUI rendering of patches.

[Alexandre Torres Porres]

Ok, seems we have yet another thread to keep discussing a same topic that I
kinda started. Anyway, if the focus of the debate has changed indeed, I
suggest changing the thread name and adding (was: "" <= old thread
subject), in this case: (was: (wip) Preferences file).

So, I did bring this up, how patches look differently in vanilla according
to the operating system, and how they look different from extended / purr
data (which, on their own, look consistent in all platforms and also look
like each other!).

Changing the font metrics from Vanilla to extended's/purr data's doesn't
compromise the patch as the other way around does. Cause opening extended
patches in the vanilla's metrics does compromise the visual experience a
lot, creating all sorts of overlaps... I already pointed this out in the
previous threads.

So, keeping it objective and not to repeat myself too much, I consider this
an issue, an undesired behaviour, a bug, whatever, and I hope we could fix
it. Any opposition? What is the best way to do this?

cheers



2017-02-21 19:05 GMT-03:00 Lucas Cordiviola :

> >> Ok, if that's the case then I would suggest not to add a user-facing
> font-metrics option.
>
> >+1
>
> >i'd also like to add, that we should not (ever) add an option with the
> sole purpose of working around bugs.
>
> Is it a bug?
>
> >if you consider the slightly different font sizes a bug (and i gather
> you do), then we should find a solution to the bug itself (rather than
> provide an easy way to make everything worse).
>
> Yes.
>
> >if you only consider them an annoyance, you might want to investigate in
> creating a gui-plugin that fixes the problem.
>
> We have a problem.
>
> >(it seems that currently, Pd-gui signals the font metrics back to
> Pd-core, which will (among other things) trigger Pd-core to load it's
> libraries. it might be worth entangling *that*)
>
> Yes, I cant override or change the variable “font_metrics” set @ line 127
> from “pd-gui.tcl” using a gui-plugin.
>
> Is it posible?
>
> I still think that shipping dejavu and hard-code Pd-extended metrics is
> full of goodness.
>
> Salutti,
> Lucarda
>
>
> >fgamdsr
> >IOhannes
>
>
>
>
> Mensaje telepatico asistido por maquinas.
>
>
>
> ___
> 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] Cross-platform uniform GUI rendering of patches.

[Lucas Cordiviola]

>> Ok, if that's the case then I would suggest not to add a user-facing 
>> font-metrics option.

>+1

>i'd also like to add, that we should not (ever) add an option with the
sole purpose of working around bugs.

Is it a bug?

>if you consider the slightly different font sizes a bug (and i gather
you do), then we should find a solution to the bug itself (rather than
provide an easy way to make everything worse).

Yes.

>if you only consider them an annoyance, you might want to investigate in
creating a gui-plugin that fixes the problem.

We have a problem.

>(it seems that currently, Pd-gui signals the font metrics back to
Pd-core, which will (among other things) trigger Pd-core to load it's
libraries. it might be worth entangling *that*)

Yes, I cant override or change the variable “font_metrics” set @ line 127 from 
“pd-gui.tcl” using a gui-plugin.

Is it posible?

I still think that shipping dejavu and hard-code Pd-extended metrics is full of 
goodness.

Salutti,
Lucarda


>fgamdsr
>IOhannes





Mensaje telepatico asistido por maquinas.


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

[PD] soundfiler features

[Ed Kelly via Pd-list]

Apologies if this is a distraction.
The soundfiler object is clearly fundamental to digital music. 
I think it needs a makeover. I'm willing to help, but it's been getting 
particularly difficult and I think, unnecessarily complicated to create patches 
that automatically load a folder of sound files which may be mono or stereo (or 
even quad?).Since this information is contained within the header of each file 
(although it's a pain with the different formats), would it not be sensible to 
have a second outlet in soundfiler that delivers the number of channels, before 
the number of samples in the file is delivered from the left outlet? Perhaps 
also other info, but what would be relevant to a patch? I think channels is a 
necessary piece of information. 

I prod you for a feature, and I probably have as many of these cattle prod 
moments hitting me from behind as I work on my patches.
Cheers,Bisous,Ed

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

For Lone Shark releases, Pure Data software and published Research, go to 
http://sharktracks.co.uk ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd + ASIO

[Christof Ressi]

> Thats right, only one app (not necessary Pd) can access the soundcard via 
> ASIO.

Ok, thanks!

> Does other ASIO software can control your focusrite? 
 
No, at least not in the way you're used to. As I've said, modern quality audio 
interfaces automatically come with multi-client ASIO drivers which means that 
several apps can access the device simultaneously. Before that, a single app 
had total control over the sound card via the ASIO driver (and could therefore 
set the latency directly, as you observed with your audio interfaces) but 
apparently that's not true any more. It wouldn't work that way because each app 
can request a different buffersize.



I'm curious if there are users on the list who have experiences with 
*multi-client* ASIO devices + Pd? I'll make some tests with different audio 
interfaces and collect the results.




Gesendet: Dienstag, 21. Februar 2017 um 04:57 Uhr
Von: "Lucas Cordiviola" 
An: "Christof Ressi" 
Cc: pd-list 
Betreff: Re: Re: [PD] Pd + ASIO

 

>> Pd controls my blocksize (ASIO buffer).
 
 

 
 
 

>Interesting. And your soundcard can't handle multiple streams, like playing 
>sound from two or more instances of Pd, right? I'm curious. 
 
 

 
 
Thats right, only one app (not necessary Pd) can access the soundcard via ASIO.
 
Just for testing:
 
Install asio4all and use it (if possible) with your built-in soundcard.
 
You will see Pd controls the asio4all buffer.
You can move the slider but is useless, along the line of that slider there's a 
zone with a different color. That`s what is controled/set & used by Pd. Iirc.
 
It could be that your trouble is related to that Focusrite has a different 
implementation on this.
 
Does other ASIO software can control your focusrite?
 
 
  
 
 

Mensaje telepatico asistido por maquinas. 



From: Christof Ressi 
Sent: Tuesday, February 21, 2017 1:46 AM
To: Lucas Cordiviola
Cc: pd-list
Subject: Aw: Re: [PD] Pd + ASIO
 
> Pd controls my blocksize (ASIO buffer).

Interesting. And your soundcard can't handle multiple streams, like playing 
sound from two or more instances of Pd, right? I'm curious.


> On fast track pro I can go to 6ms IO, (with block size 256)

that's nice :-)

 
> What is MixControl ?

Focusrite software for the Scarlett interface. Similar to RME's TotalMix.

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