Hi list!
I got a more clear response from the organizers on this issue than anything I've seen in this thread so far - here it is:
Hi Ben,
thanks for your Interest in our Call.
We accepts only patches made with Kyma or Max/MSP due the fact we are not able to provide financial support for the two selected composers. So it is possible that they will not be able to be in Milan for the concert. To avoid technical issues we choose the plattforms we already use in our work or we are very familiar with. This is the only reason. If the selected composer can assure us to be available for the concert the can be used any piece of software/hardware.
I hope this helps.
Many thanks
Federico Placidi
I can't think of a better example of the vicious cycle of software lock-in than this. They don't have money to offer financial support, so they have to rely on the tools that they know, which are proprietary and expensive, thus making it even less likely that a composer would be able to afford to travel to the concert (because he/she had to spend money on either Max/MSP or Kyma to composer the piece in the first place).
-Jonathan
----- Original Message -----
From: Ben Baker-Smith bbakersmith@gmail.com To: pd list pd-list@iem.at Cc: Sent: Tuesday, January 10, 2012 4:12 PM Subject: Re: [PD] no pd?? WTF ????
Hi list!
I got a more clear response from the organizers on this issue than anything I've seen in this thread so far - here it is:
Hi Ben,
thanks for your Interest in our Call.
We accepts only patches made with Kyma or Max/MSP due the fact we are not
able to provide
financial support for the two selected composers. So it is possible that
they will not be able to be in Milan for the concert.
To avoid technical issues we choose the plattforms we already use in our
work or we are very familiar with.
This is the only reason. If the selected composer can assure us to be available for the concert the
can be used any piece of software/hardware.
I hope this helps.
Many thanks
Federico Placidi
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Not a bad point... but, or more likely because they are supporting only those artists able to afford such things as expensive software, travel and food.
On Wed, Jan 11, 2012 at 9:48 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
I can't think of a better example of the vicious cycle of software lock-in than this. They don't have money to offer financial support, so they have to rely on the tools that they know, which are proprietary and expensive, thus making it even less likely that a composer would be able to afford to travel to the concert (because he/she had to spend money on either Max/MSP or Kyma to composer the piece in the first place).
-Jonathan
----- Original Message -----
From: Ben Baker-Smith bbakersmith@gmail.com To: pd list pd-list@iem.at Cc: Sent: Tuesday, January 10, 2012 4:12 PM Subject: Re: [PD] no pd?? WTF ????
Hi list!
I got a more clear response from the organizers on this issue than anything I've seen in this thread so far - here it is:
Hi Ben,
thanks for your Interest in our Call.
We accepts only patches made with Kyma or Max/MSP due the fact we are
not
able to provide
financial support for the two selected composers. So it is possible
that
they will not be able to be in Milan for the concert.
To avoid technical issues we choose the plattforms we already use in
our
work or we are very familiar with.
This is the only reason. If the selected composer can assure us to be available for the concert
the
can be used any piece of software/hardware.
I hope this helps.
Many thanks
Federico Placidi
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
No, there really are music students out there looking at what they need in order to be successful, and
when most of the voices around them are aggressively (and often ignorantly) suggesting only
proprietary tools that cost lots of money, these students save up their meager resources in order to
buy them. I'm talking about students who are probably already in debt from loans, and it's quite common
that they max out on their technology budget and as a consequence are unable to attend a
festival.
What's even worse is that these constrained options lead to a lot of those students downloading
cracked copies of proprietary software (and the negative effects there usually manifest themselves
more quickly and concretely).
-Jonathan
From: Richie Cyngler glitchpop@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Ben Baker-Smith bbakersmith@gmail.com; pd list pd-list@iem.at Sent: Tuesday, January 10, 2012 5:53 PM Subject: Re: [PD] no pd?? WTF ????
Not a bad point... but, or more likely because they are supporting only those artists able to afford such things as expensive software, travel and food.
On Wed, Jan 11, 2012 at 9:48 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
I can't think of a better example of the vicious cycle of software lock-in than this.
They don't have money to offer financial support, so they have to rely on the tools that they know, which are proprietary and expensive, thus making it even less likely that a composer would be able to afford to travel to the concert (because he/she had to spend money on either Max/MSP or Kyma to composer the piece in the first place).
-Jonathan
----- Original Message -----
From: Ben Baker-Smith bbakersmith@gmail.com To: pd list pd-list@iem.at Cc: Sent: Tuesday, January 10, 2012 4:12 PM Subject: Re: [PD] no pd?? WTF ????
Hi list!
I got a more clear response from the organizers on this issue than anything I've seen in this thread so far - here it is:
Hi Ben,
thanks for your Interest in our Call.
We accepts only patches made with Kyma or Max/MSP due the fact we are not
able to provide
financial support for the two selected composers. So it is possible that
they will not be able to be in Milan for the concert.
To avoid technical issues we choose the plattforms we already use in our
work or we are very familiar with.
This is the only reason. If the selected composer can assure us to be available for the concert the
can be used any piece of software/hardware.
I hope this helps.
Many thanks
Federico Placidi
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Richie
I would not try to crack Max/Msp, nor do any of my students engage in such poor practices I took a Kyma class in Grad school, it sounded awesome but was way out of my price range of course
From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Jonathan Wilkes Sent: Tuesday, January 10, 2012 6:24 PM To: Richie Cyngler Cc: pd list; Ben Baker-Smith Subject: Re: [PD] no pd?? WTF ????
No, there really are music students out there looking at what they need in order to be successful, and when most of the voices around them are aggressively (and often ignorantly) suggesting only proprietary tools that cost lots of money, these students save up their meager resources in order to buy them. I'm talking about students who are probably already in debt from loans, and it's quite common that they max out on their technology budget and as a consequence are unable to attend a festival.
What's even worse is that these constrained options lead to a lot of those students downloading cracked copies of proprietary software (and the negative effects there usually manifest themselves more quickly and concretely).
-Jonathan
From: Richie Cyngler <glitchpop@gmail.commailto:glitchpop@gmail.com> To: Jonathan Wilkes <jancsika@yahoo.commailto:jancsika@yahoo.com> Cc: Ben Baker-Smith <bbakersmith@gmail.commailto:bbakersmith@gmail.com>; pd list <pd-list@iem.atmailto:pd-list@iem.at> Sent: Tuesday, January 10, 2012 5:53 PM Subject: Re: [PD] no pd?? WTF ???? Not a bad point... but, or more likely because they are supporting only those artists able to afford such things as expensive software, travel and food. On Wed, Jan 11, 2012 at 9:48 AM, Jonathan Wilkes <jancsika@yahoo.commailto:jancsika@yahoo.com> wrote: I can't think of a better example of the vicious cycle of software lock-in than this. They don't have money to offer financial support, so they have to rely on the tools that they know, which are proprietary and expensive, thus making it even less likely that a composer would be able to afford to travel to the concert (because he/she had to spend money on either Max/MSP or Kyma to composer the piece in the first place).
-Jonathan
----- Original Message -----
From: Ben Baker-Smith <bbakersmith@gmail.commailto:bbakersmith@gmail.com> To: pd list <pd-list@iem.atmailto:pd-list@iem.at> Cc: Sent: Tuesday, January 10, 2012 4:12 PM Subject: Re: [PD] no pd?? WTF ????
Hi list!
I got a more clear response from the organizers on this issue than anything I've seen in this thread so far - here it is:
Hi Ben,
thanks for your Interest in our Call.
We accepts only patches made with Kyma or Max/MSP due the fact we are not
able to provide
financial support for the two selected composers. So it is possible that
they will not be able to be in Milan for the concert.
To avoid technical issues we choose the plattforms we already use in our
work or we are very familiar with.
This is the only reason. If the selected composer can assure us to be available for the concert the
can be used any piece of software/hardware.
I hope this helps.
Many thanks
Federico Placidi
Pd-list@iem.atmailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.atmailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Richie
From: "Pagano, Patrick" pat@digitalworlds.ufl.edu To: Jonathan Wilkes jancsika@yahoo.com; Richie Cyngler glitchpop@gmail.com Cc: pd list pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com Sent: Tuesday, January 10, 2012 6:33 PM Subject: RE: [PD] no pd?? WTF ????
I would not try to crack Max/Msp, nor do any of my students engage in such poor practices
Do you require them to use Max?
I took a Kyma class in Grad school, it sounded awesome but was way out of my price range of course From:pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Jonathan Wilkes Sent: Tuesday, January 10, 2012 6:24 PM To: Richie Cyngler Cc: pd list; Ben Baker-Smith Subject: Re: [PD] no pd?? WTF ???? No, there really are music students out there looking at what they need in order to be successful, and when most of the voices around them are aggressively (and often ignorantly) suggesting only proprietary tools that cost lots of money, these students save up their meager resources in order to buy them. I'm talking about students who are probably already in debt from loans, and it's quite common that they max out on their technology budget and as a consequence are unable to attend a festival. What's even worse is that these constrained options lead to a lot of those students downloading cracked copies of proprietary software (and the negative effects there usually manifest themselves more quickly and concretely). -Jonathan
From:Richie Cyngler glitchpop@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Ben Baker-Smith bbakersmith@gmail.com; pd list pd-list@iem.at Sent: Tuesday, January 10, 2012 5:53 PM Subject: Re: [PD] no pd?? WTF ???? Not a bad point... but, or more likely because they are supporting only those artists able to afford such things as expensive software, travel and food. On Wed, Jan 11, 2012 at 9:48 AM, Jonathan Wilkes jancsika@yahoo.com wrote: I can't think of a better example of the vicious cycle of software lock-in than this. They don't have money to offer financial support, so they have to rely on the tools that they know, which are proprietary and expensive, thus making it even less likely that a composer would be able to afford to travel to the concert (because he/she had to spend money on either Max/MSP or Kyma to composer the piece in the first place).
-Jonathan
----- Original Message -----
From: Ben Baker-Smith bbakersmith@gmail.com To: pd list pd-list@iem.at Cc: Sent: Tuesday, January 10, 2012 4:12 PM Subject: Re: [PD] no pd?? WTF ????
Hi list!
I got a more clear response from the organizers on this issue than anything I've seen in this thread so far - here it is:
Hi Ben,
thanks for your Interest in our Call.
We accepts only patches made with Kyma or Max/MSP due the fact we are not
able to provide
financial support for the two selected composers. So it is possible that
they will not be able to be in Milan for the concert.
To avoid technical issues we choose the plattforms we already use in our
work or we are very familiar with.
This is the only reason. If the selected composer can assure us to be available for the concert the
can be used any piece of software/hardware.
I hope this helps.
Many thanks
Federico Placidi
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Richie
You're right Jonathan, I completely agree. I really shouldn't post things until I've had breakfast. Or try to be light and ironic on topics that I believe strongly in, i.e. cynicism != useful in most situations.
On Wed, Jan 11, 2012 at 10:23 AM, Jonathan Wilkes jancsika@yahoo.comwrote:
No, there really are music students out there looking at what they need in order to be successful, and when most of the voices around them are aggressively (and often ignorantly) suggesting only proprietary tools that cost lots of money, these students save up their meager resources in order to buy them. I'm talking about students who are probably already in debt from loans, and it's quite common that they max out on their technology budget and as a consequence are unable to attend a festival.
What's even worse is that these constrained options lead to a lot of those students downloading cracked copies of proprietary software (and the negative effects there usually manifest themselves more quickly and concretely).
-Jonathan
*From:* Richie Cyngler glitchpop@gmail.com *To:* Jonathan Wilkes jancsika@yahoo.com *Cc:* Ben Baker-Smith bbakersmith@gmail.com; pd list pd-list@iem.at *Sent:* Tuesday, January 10, 2012 5:53 PM
*Subject:* Re: [PD] no pd?? WTF ????
Not a bad point... but, or more likely because they are supporting only those artists able to afford such things as expensive software, travel and food.
On Wed, Jan 11, 2012 at 9:48 AM, Jonathan Wilkes jancsika@yahoo.comwrote:
I can't think of a better example of the vicious cycle of software lock-in than this. They don't have money to offer financial support, so they have to rely on the tools that they know, which are proprietary and expensive, thus making it even less likely that a composer would be able to afford to travel to the concert (because he/she had to spend money on either Max/MSP or Kyma to composer the piece in the first place).
-Jonathan
----- Original Message -----
From: Ben Baker-Smith bbakersmith@gmail.com To: pd list pd-list@iem.at Cc: Sent: Tuesday, January 10, 2012 4:12 PM Subject: Re: [PD] no pd?? WTF ????
Hi list!
I got a more clear response from the organizers on this issue than anything I've seen in this thread so far - here it is:
Hi Ben,
thanks for your Interest in our Call.
We accepts only patches made with Kyma or Max/MSP due the fact we are
not
able to provide
financial support for the two selected composers. So it is possible
that
they will not be able to be in Milan for the concert.
To avoid technical issues we choose the plattforms we already use in
our
work or we are very familiar with.
This is the only reason. If the selected composer can assure us to be available for the concert
the
can be used any piece of software/hardware.
I hope this helps.
Many thanks
Federico Placidi
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Richie
And that's not the end of the vicious cycle. Students who saved their money to buy a Max license are often unwilling to accept that their work could have been done as easy in Pd, and sometimes even better and/or easier. Often they use and stick to Max simply because they have spent the money on it. They then keep paying for the updates. this is referred to as the concorde effect.
M
Am 11.01.2012 um 00:23 schrieb Jonathan Wilkes:
No, there really are music students out there looking at what they need in order to be successful, and when most of the voices around them are aggressively (and often ignorantly) suggesting only proprietary tools that cost lots of money, these students save up their meager resources in order to buy them. I'm talking about students who are probably already in debt from loans, and it's quite common that they max out on their technology budget and as a consequence are unable to attend a festival.
What's even worse is that these constrained options lead to a lot of those students downloading cracked copies of proprietary software (and the negative effects there usually manifest themselves more quickly and concretely).
-Jonathan
From: Richie Cyngler glitchpop@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Ben Baker-Smith bbakersmith@gmail.com; pd list pd-list@iem.at Sent: Tuesday, January 10, 2012 5:53 PM Subject: Re: [PD] no pd?? WTF ????
Not a bad point... but, or more likely because they are supporting only those artists able to afford such things as expensive software, travel and food.
On Wed, Jan 11, 2012 at 9:48 AM, Jonathan Wilkes jancsika@yahoo.com wrote: I can't think of a better example of the vicious cycle of software lock-in than this. They don't have money to offer financial support, so they have to rely on the tools that they know, which are proprietary and expensive, thus making it even less likely that a composer would be able to afford to travel to the concert (because he/she had to spend money on either Max/MSP or Kyma to composer the piece in the first place).
-Jonathan
----- Original Message -----
From: Ben Baker-Smith bbakersmith@gmail.com To: pd list pd-list@iem.at Cc: Sent: Tuesday, January 10, 2012 4:12 PM Subject: Re: [PD] no pd?? WTF ????
Hi list!
I got a more clear response from the organizers on this issue than anything I've seen in this thread so far - here it is:
Hi Ben,
thanks for your Interest in our Call.
We accepts only patches made with Kyma or Max/MSP due the fact we are not
able to provide
financial support for the two selected composers. So it is possible that
they will not be able to be in Milan for the concert.
To avoid technical issues we choose the plattforms we already use in our
work or we are very familiar with.
This is the only reason. If the selected composer can assure us to be available for the concert the
can be used any piece of software/hardware.
I hope this helps.
Many thanks
Federico Placidi
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Richie
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Max abonnements@revolwear.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Richie Cyngler glitchpop@gmail.com; pd list pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com Sent: Wednesday, January 11, 2012 7:09 AM Subject: Re: [PD] no pd?? WTF ????
And that's not the end of the vicious cycle. Students who saved their money to buy a Max license are often unwilling to accept that their work could have been done as easy in Pd, and sometimes even better and/or easier.
If you think of free software as an ethical issue like I do and are talking about free programs that have a proprietary alternative, there is still an important division between those programs that are free and superior to their proprietary counterparts on practical grounds, and those that don't have the same feature set as their proprietary counterparts (but are still quite good).
In terms of ease of patching, Pd is clearly in the latter camp-- Max has infinite undo, a "Tidy Up" that actually _does_ something useful, and a set of externals that allows to make multiple connections at once and lots of other shortcuts (maybe these are part of the core now, I'm not sure). Plus tooltips, anchors to resize guis/boxes/messages, and probably lots of other things that make patching easier.
I use Pd and free software (almost) exclusively, but we should be clear about which features are available and which are not.
-Jonathan
Often they use and stick to Max simply because they have spent the money on it. They then keep paying for the updates. this is referred to as the concorde effect.
M
Am 11.01.2012 um 00:23 schrieb Jonathan Wilkes:
No, there really are music students out there looking at what they need in
order to be successful, and
when most of the voices around them are aggressively (and often ignorantly)
suggesting only
proprietary tools that cost lots of money, these students save up their
meager resources in order to
buy them. I'm talking about students who are probably already in debt
from loans, and it's quite common
that they max out on their technology budget and as a consequence are
unable to attend a
festival.
What's even worse is that these constrained options lead to a lot of
those students downloading
cracked copies of proprietary software (and the negative effects there
usually manifest themselves
more quickly and concretely).
-Jonathan
From: Richie Cyngler glitchpop@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Ben Baker-Smith bbakersmith@gmail.com; pd list
Sent: Tuesday, January 10, 2012 5:53 PM Subject: Re: [PD] no pd?? WTF ????
Not a bad point... but, or more likely because they are supporting only
those artists able to afford such things as expensive software, travel and food.
On Wed, Jan 11, 2012 at 9:48 AM, Jonathan Wilkes jancsika@yahoo.com
wrote:
I can't think of a better example of the vicious cycle of software
lock-in than this.
They don't have money to offer financial support, so they have to rely
on the tools
that they know, which are proprietary and expensive, thus making it even
less likely
that a composer would be able to afford to travel to the concert (because
he/she
had to spend money on either Max/MSP or Kyma to composer the piece in the
first
place).
-Jonathan
----- Original Message -----
From: Ben Baker-Smith bbakersmith@gmail.com To: pd list pd-list@iem.at Cc: Sent: Tuesday, January 10, 2012 4:12 PM Subject: Re: [PD] no pd?? WTF ????
Hi list!
I got a more clear response from the organizers on this issue than anything I've seen in this thread so far - here it is:
Hi Ben,
thanks for your Interest in our Call.
We accepts only patches made with Kyma or Max/MSP due the fact we
are not
able to provide
financial support for the two selected composers. So it is
possible that
they will not be able to be in Milan for the concert.
To avoid technical issues we choose the plattforms we already use
in our
work or we are very familiar with.
This is the only reason. If the selected composer can assure us to be available for the
concert the
can be used any piece of software/hardware.
I hope this helps.
Many thanks
Federico Placidi
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Richie
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
On Jan 12, 2012, at 6:56 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Richie Cyngler glitchpop@gmail.com; pd list pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com Sent: Wednesday, January 11, 2012 7:09 AM Subject: Re: [PD] no pd?? WTF ????
And that's not the end of the vicious cycle. Students who saved their money to buy a Max license are often unwilling to accept that their work could have been done as easy in Pd, and sometimes even better and/or easier.
If you think of free software as an ethical issue like I do and are talking about free programs that have a proprietary alternative, there is still an important division between those programs that are free and superior to their proprietary counterparts on practical grounds, and those that don't have the same feature set as their proprietary counterparts (but are still quite good).
In terms of ease of patching, Pd is clearly in the latter camp-- Max has infinite undo, a "Tidy Up" that actually _does_ something useful, and a set of externals that allows to make multiple connections at once and lots of other shortcuts (maybe these are part of the core now, I'm not sure). Plus tooltips, anchors to resize guis/boxes/messages, and probably lots of other things that make patching easier.
I use Pd and free software (almost) exclusively, but we should be clear about which features are available and which are not.
Excellent point.
Speaking of, is your tooltips patch fully functional in Pd-extended 0.43? I believe it is included, right? It would be great to ship with that working.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Max abonnements@revolwear.com; pd list pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com Sent: Thursday, January 12, 2012 8:50 PM Subject: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
On Jan 12, 2012, at 6:56 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Richie Cyngler glitchpop@gmail.com; pd list
pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com
Sent: Wednesday, January 11, 2012 7:09 AM Subject: Re: [PD] no pd?? WTF ????
And that's not the end of the vicious cycle. Students who saved their money to buy a Max license are often unwilling
to
accept that their work could have been done as easy in Pd, and
sometimes even
better and/or easier.
If you think of free software as an ethical issue like I do and are talking about free programs
that have a
proprietary alternative, there is still an important division between those
programs that are
free and superior to their proprietary counterparts on practical grounds,
and those that
don't have the same feature set as their proprietary counterparts (but
are still quite good).
In terms of ease of patching, Pd is clearly in the latter camp-- Max has
infinite undo, a
"Tidy Up" that actually _does_ something useful, and a set of
externals that allows to make
multiple connections at once and lots of other shortcuts (maybe these are
part of the core now,
I'm not sure). Plus tooltips, anchors to resize guis/boxes/messages,
and probably lots of
other things that make patching easier.
I use Pd and free software (almost) exclusively, but we should be clear
about which features
are available and which are not.
Excellent point.
Speaking of, is your tooltips patch fully functional in Pd-extended 0.43? I believe it is included, right? It would be great to ship with that working.
There was the problem that if you did [loadbang]-[tip 1 blah blah blah(-[s pd-this-canvas.pd] the label doesn't get the right width. I tried using the <<Loaded>> virtual event and it didn't work, and then I think you said that the patch should be finished drawing before <<Loaded>> happens.
I could just use after idle or update idletasks but those are heavily critiqued on the tcl wiki...
-Jonathan
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
On Jan 12, 2012, at 10:08 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Max abonnements@revolwear.com; pd list pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com Sent: Thursday, January 12, 2012 8:50 PM Subject: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
On Jan 12, 2012, at 6:56 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Richie Cyngler glitchpop@gmail.com; pd list
pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com
Sent: Wednesday, January 11, 2012 7:09 AM Subject: Re: [PD] no pd?? WTF ????
And that's not the end of the vicious cycle. Students who saved their money to buy a Max license are often unwilling
to
accept that their work could have been done as easy in Pd, and
sometimes even
better and/or easier.
If you think of free software as an ethical issue like I do and are talking about free programs
that have a
proprietary alternative, there is still an important division between those
programs that are
free and superior to their proprietary counterparts on practical grounds,
and those that
don't have the same feature set as their proprietary counterparts (but
are still quite good).
In terms of ease of patching, Pd is clearly in the latter camp-- Max has
infinite undo, a
"Tidy Up" that actually _does_ something useful, and a set of
externals that allows to make
multiple connections at once and lots of other shortcuts (maybe these are
part of the core now,
I'm not sure). Plus tooltips, anchors to resize guis/boxes/messages,
and probably lots of
other things that make patching easier.
I use Pd and free software (almost) exclusively, but we should be clear
about which features
are available and which are not.
Excellent point.
Speaking of, is your tooltips patch fully functional in Pd-extended 0.43? I believe it is included, right? It would be great to ship with that working.
There was the problem that if you did [loadbang]-[tip 1 blah blah blah(-[s pd-this-canvas.pd] the label doesn't get the right width. I tried using the <<Loaded>> virtual event and it didn't work, and then I think you said that the patch should be finished drawing before <<Loaded>> happens.
I could just use after idle or update idletasks but those are heavily critiqued on the tcl wiki...
'update' is bad news, but 'after idle' is fine. It just might lead to tricky bugs since things will not necessarily execute in the order you might think.
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Max abonnements@revolwear.com; pd list pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com Sent: Thursday, January 12, 2012 11:20 PM Subject: Re: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
On Jan 12, 2012, at 10:08 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Max abonnements@revolwear.com; pd list
pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com
Sent: Thursday, January 12, 2012 8:50 PM Subject: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
On Jan 12, 2012, at 6:56 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Richie Cyngler glitchpop@gmail.com; pd list
pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com
Sent: Wednesday, January 11, 2012 7:09 AM Subject: Re: [PD] no pd?? WTF ????
And that's not the end of the vicious cycle. Students who saved their money to buy a Max license are often
unwilling
to
accept that their work could have been done as easy in Pd, and
sometimes even
better and/or easier.
If you think of free software as an ethical issue like I do and are talking about free
programs
that have a
proprietary alternative, there is still an important division
between those
programs that are
free and superior to their proprietary counterparts on practical
grounds,
and those that
don't have the same feature set as their proprietary
counterparts (but
are still quite good).
In terms of ease of patching, Pd is clearly in the latter camp--
Max has
infinite undo, a
"Tidy Up" that actually _does_ something useful, and a
set of
externals that allows to make
multiple connections at once and lots of other shortcuts (maybe
these are
part of the core now,
I'm not sure). Plus tooltips, anchors to resize
guis/boxes/messages,
and probably lots of
other things that make patching easier.
I use Pd and free software (almost) exclusively, but we should be
clear
about which features
are available and which are not.
Excellent point.
Speaking of, is your tooltips patch fully functional in Pd-extended
0.43? I
believe it is included, right? It would be great to ship with that
working.
There was the problem that if you did [loadbang]-[tip 1 blah blah blah(-[s
pd-this-canvas.pd]
the label doesn't get the right width. I tried using the
<<Loaded>> virtual event and it didn't
work, and then I think you said that the patch should be finished drawing
before <<Loaded>>
happens.
I could just use after idle or update idletasks but those are heavily
critiqued on the tcl wiki...
'update' is bad news, but 'after idle' is fine. It just might lead to tricky bugs since things will not necessarily execute in the order you might think.
The "tricky bugs" warning was what made me not want to use 'after idle'. I think in another thread you agreed that <<Loaded>> should get triggered after the patch is drawn, so a quick and dirty solution would put 'after idle' right before the <<Loaded>> virtual event in the relevant proc (with a comment that this isn't the best solution). If that sounds like a bad idea, then the tooltips patch shouldn't be included until <<Loaded>> works correctly.
Unless there's another solution I'm not thinking of...
-Jonathan
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On Jan 13, 2012, at 12:59 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Max abonnements@revolwear.com; pd list pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com Sent: Thursday, January 12, 2012 11:20 PM Subject: Re: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
On Jan 12, 2012, at 10:08 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Max abonnements@revolwear.com; pd list
pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com
Sent: Thursday, January 12, 2012 8:50 PM Subject: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
On Jan 12, 2012, at 6:56 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Richie Cyngler glitchpop@gmail.com; pd list
pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com
Sent: Wednesday, January 11, 2012 7:09 AM Subject: Re: [PD] no pd?? WTF ????
And that's not the end of the vicious cycle. Students who saved their money to buy a Max license are often
unwilling
to
accept that their work could have been done as easy in Pd, and
sometimes even
better and/or easier.
If you think of free software as an ethical issue like I do and are talking about free
programs
that have a
proprietary alternative, there is still an important division
between those
programs that are
free and superior to their proprietary counterparts on practical
grounds,
and those that
don't have the same feature set as their proprietary
counterparts (but
are still quite good).
In terms of ease of patching, Pd is clearly in the latter camp--
Max has
infinite undo, a
"Tidy Up" that actually _does_ something useful, and a
set of
externals that allows to make
multiple connections at once and lots of other shortcuts (maybe
these are
part of the core now,
I'm not sure). Plus tooltips, anchors to resize
guis/boxes/messages,
and probably lots of
other things that make patching easier.
I use Pd and free software (almost) exclusively, but we should be
clear
about which features
are available and which are not.
Excellent point.
Speaking of, is your tooltips patch fully functional in Pd-extended
0.43? I
believe it is included, right? It would be great to ship with that
working.
There was the problem that if you did [loadbang]-[tip 1 blah blah blah(-[s
pd-this-canvas.pd]
the label doesn't get the right width. I tried using the
<<Loaded>> virtual event and it didn't
work, and then I think you said that the patch should be finished drawing
before <<Loaded>>
happens.
I could just use after idle or update idletasks but those are heavily
critiqued on the tcl wiki...
'update' is bad news, but 'after idle' is fine. It just might lead to tricky bugs since things will not necessarily execute in the order you might think.
The "tricky bugs" warning was what made me not want to use 'after idle'. I think in another thread you agreed that <<Loaded>> should get triggered after the patch is drawn, so a quick and dirty solution would put 'after idle' right before the <<Loaded>> virtual event in the relevant proc (with a comment that this isn't the best solution). If that sounds like a bad idea, then the tooltips patch shouldn't be included until <<Loaded>> works correctly.
Unless there's another solution I'm not thinking of...
Fixing <<Loaded>> is probably a bigger thing than I can manage for the Pd-extended 0.43 release, but patches are welcome. So the question of the moment is: are the tooltips usable enough to leave them in? Do they cause any problems?
.hc
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Max abonnements@revolwear.com; pd list pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com Sent: Sunday, January 15, 2012 5:34 PM Subject: Re: Tooltips in Pd-extended 0.43 WAS: no pd?? WTF ????
[...]
Fixing <<Loaded>> is probably a bigger thing than I can manage for the Pd-extended 0.43 release, but patches are welcome. So the question of the moment is: are the tooltips usable enough to leave them in? Do they cause any problems?
.hc
Yes they are usable. Problems are:
- aforementioned loadbanging problem with formatting the label correctly
- if you select an object, get a tooltip on it, then delete it before generating a <Leave>
event, the tooltip will persist until you mouse over (and leave) some other object
- a little tricky to generate a outlet tooltip for iemgui outlets (small "hotspot" area for some reason)
- since iemguis don't have a classwide tag for the object you can't get tooltips for them (only for their xlets)
unless you make a label and position it on top of the iemgui
Some things to be improved:
- if the canvas goes below the bottom of the screen the tooltip should probably be shown on the lowest
part of the canvas still showing
- delay for the tooltip (dis)appearance could probably be tweaked
- the "Edit mode" finger pointer has to be a little bit above the xlet to trigger the activeborder. Also, you can
still be pointing at the activebordered xlet but not be over a hotspot that would trigger drawing a connection, which is annoying.
- Something like [osc~] takes a float or signal to its left inlet, but it'd also be nice to display what those data
types are supposed to mean in the context of the object. So instead of:
"Inlet 0 of osc~: float signal"
Something like
"Inlet 0 of osc~ (frequency): float signal"
Not sure how to change the PDDP tag to accommodate that:
INLET_0 float signal
?
-Jonathan
And that's not the end of the vicious cycle. Students who saved their money to buy a Max license are often unwilling
to accept that their work could have been done as easy in Pd, and
sometimes even better and/or easier.If you think of free software as an ethical issue like I do and are talking about free
programs that have a proprietary alternative, there is still an important division between
those programs that are free and superior to their proprietary counterparts on practical
grounds, and those that don't have the same feature set as their proprietary counterparts (but
are still quite good).In terms of ease of patching, Pd is clearly in the latter camp-- Max has
infinite undo, a "Tidy Up" that actually _does_ something useful, and a set of externals
that allows to make multiple connections at once and lots of other shortcuts (maybe these
are part of the core now, I'm not sure). Plus tooltips, anchors to resize guis/boxes/messages,
and probably lots of other things that make patching easier.I use Pd and free software (almost) exclusively, but we should be clear
about which features are available and which are not.
and you're only talking about the aesthetical/workflow features. to bring
up a subject that I am paying attention only now, try out to see how high
you go with [expr pow(2,$f1)] until you loose resolution - 20 in pd, but
30 in max5 (the coming up of Pd double precision will help this, but it's
a work Katja is doing alone).
Which means, for example, in max you have more resolution than Pd to
control the playback of large arrays with precision (up to 2147483647,
around 12h of audio at 48KHz). High moral feeling (i.e. the "we're better
because we're free" logo) isn't enough for precision dsp.
Le 2012-01-13 à 10:46:00, João Pais a écrit :
and you're only talking about the aesthetical/workflow features. to bring up a subject that I am paying attention only now, try out to see how high you go with [expr pow(2,$f1)] until you loose resolution - 20 in pd, but 30 in max5 (the coming up of Pd double precision will help this, but it's a work Katja is doing alone).
There's a big difference between decimal precision as printed on screen and in text files and [netsend], and binary precision used in most other situations.
Pd is able to think of numbers bigger than a million, but won't print a million plus one. It is able to if you force it to, using less than ideal tools such as [makefilename] that creates one symbol each time, or [#sprintf] that makes you a float list of ascii codes.
Neither binary nor decimal representation is more precise than the other, it's just that their precision never matches exactly. 20 bits is slightly less than 6 decimals, whereas 16 decimals is slightly more than 53 bits. Thus you can only preserve precision by using slightly too many digits, otherwise you'll have too few.
I don't know what max5 does, but the only practical float sizes in the main processor are 24 bits and 53 bits. (this assumes that the most significant bit is not recorded because it's always one)
Which means, for example, in max you have more resolution than Pd to control the playback of large arrays with precision (up to 2147483647,
that's 31 bits. From 0 to 2147483647, you have 2147483648 numbers, which is pow(2,31) exactly (aka 1<<31), if it didn't overflow. the 32nd bit is the sign. That's using integers. I bet that you can't have integer signals. Can you ? Otherwise, you're stuck at the same limit as Pd... though Pd42 does offer a workaround as a 2nd inlet in [tabread~].
Does Max offer that 2nd inlet ?
BTW : in floats, pd can exactly represent powers of two up to pow(2,127). Powers of two are represented exactly in binary. They just won't be printed exactly in decimal by default, but [makefilename %f] can print «symbol 170141183460469231731687303715884105728.000000» accurately. The float format stops working just before getting to pow(2,128). But for [tabread~] you need contiguous integers, and that stops at 16777216, and for [tabread4~] you need at least some fractions to make it useful at all (contiguous sixteenths stop at 1048576, for example). So, your power-of-2 example is misleading in another way.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2012-01-13 à 08:05:00, Mathieu Bouchard a écrit :
Neither binary nor decimal representation is more precise than the other, it's just that their precision never matches exactly. 20 bits is slightly less than 6 decimals, whereas 16 decimals is slightly more than 53 bits. Thus you can only preserve precision by using slightly too many digits, otherwise you'll have too few.
erratum : i meant that 20 bits is slightly more than 6 decimals.
20 bits = 6.0205... decimals 24 bits = 7.2247... decimals 53 bits = 15.9545... decimals
(And by «decimal» here, I mean all significant digits, not the other meaning of the word)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
But whatever the theoretical precision of a float, I think the thing that makes Pd floats less precise than Max floats lies in the use of the %g format specifier to print them out, which can result in a lower precision than the float is capable of. This makes it possible to use maximum precision float calculations inside of objects but not between them. (and of course nothing stops an object using doubles internally.)
Martin
On 2012-01-13 08:11, Mathieu Bouchard wrote:
Le 2012-01-13 à 08:05:00, Mathieu Bouchard a écrit :
Neither binary nor decimal representation is more precise than the other, it's just that their precision never matches exactly. 20 bits is slightly less than 6 decimals, whereas 16 decimals is slightly more than 53 bits. Thus you can only preserve precision by using slightly too many digits, otherwise you'll have too few.
erratum : i meant that 20 bits is slightly more than 6 decimals.
20 bits = 6.0205... decimals 24 bits = 7.2247... decimals 53 bits = 15.9545... decimals
(And by «decimal» here, I mean all significant digits, not the other meaning of the word)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2012-01-13 à 09:06:00, Martin Peach a écrit :
But whatever the theoretical precision of a float, I think the thing that makes Pd floats less precise than Max floats lies in the use of the %g format specifier to print them out, which can result in a lower precision than the float is capable of.
The %g specifier is able to print at full precision, if you instruct it to, but pd only uses something like %.6g, whereas you'd need %.8g to conserve all the binary precision (%.7g is slightly not enough, %.8g is too much, but there's not a %.7½g).
To conserve the decimal precision, however, you flip it around : in a 32-bit float, you can only load a %.7g without loss, and a %.8g won't fit. But this only applies if the data really has %.8g precision to start with, which is not the case with %.8g numbers that came from float32, which really have only 7.2247 decimals of precision, which fits exactly in float32.
This makes it possible to use maximum precision float calculations inside of objects but not between them.
Between two objects communicating by float messages from outlet to inlet, things happen only in binary, and you already know that. This means that you can have 24-bit float32 precision between objects. The drop to 19.93 bits of precision (%.6g) occurs only when converting to decimal ascii text and back.
Right ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
I think Pd uses %g which probably means %.6g by default, but it looks more like %.5g.
You're right, the precision is only lost when the patcher is written out somewhere.
In the attached patcher clicking on [1( calculates pi, which gets printed to a number box and the screen in 5 digit precision as 3.14159, but the subsequent [sin] object gives a value much closer to zero than when you click on [3.14159(, so the numbber box is hiding some extra precision.
Martin
But whatever the theoretical precision of a float, I think the thing that makes Pd floats less precise than Max floats lies in the use of the %g format specifier to print them out, which can result in a lower precision than the float is capable of.
The %g specifier is able to print at full precision, if you instruct it to, but pd only uses something like %.6g, whereas you'd need %.8g to conserve all the binary precision (%.7g is slightly not enough, %.8g is too much, but there's not a %.7½g).
To conserve the decimal precision, however, you flip it around : in a 32-bit float, you can only load a %.7g without loss, and a %.8g won't fit. But this only applies if the data really has %.8g precision to start with, which is not the case with %.8g numbers that came from float32, which really have only 7.2247 decimals of precision, which fits exactly in float32.
This makes it possible to use maximum precision float calculations inside of objects but not between them.
Between two objects communicating by float messages from outlet to inlet, things happen only in binary, and you already know that. This means that you can have 24-bit float32 precision between objects. The drop to 19.93 bits of precision (%.6g) occurs only when converting to decimal ascii text and back.
Right ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Here's a more complete example of the precision thing.
Martin
Le 2012-01-13 à 20:12:00, martin.peach@sympatico.ca a écrit :
In the attached patcher clicking on [1( calculates pi, which gets printed to a number box and the screen in 5 digit precision as 3.14159, but the subsequent [sin] object gives a value much closer to zero than when you click on [3.14159(, so the numbber box is hiding some extra precision.
When x is close to pi, sin(x) is close to x-pi.
Neat trick for computing an approximation of x-pi without having to state what pi is.
Though you could actually do [expr x-2*asin(1)] instead.
The difference between sin(x) and x-pi is only about ⅓(x-pi)², so it doesn't really matter.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
and you're only talking about the aesthetical/workflow features. to
bring up a subject that I am paying attention only now, try out to see how high
you go with [expr pow(2,$f1)] until you loose resolution - 20 in pd, but 30 in
max5 (the coming up of Pd double precision will help this, but it's a work
Katja is doing alone).There's a big difference between decimal precision as printed on screen and in text files and [netsend], and binary precision used in most other situations.
Pd is able to think of numbers bigger than a million, but won't print a million plus one. It is able to if you force it to, using less than ideal tools such as [makefilename] that creates one symbol each time, or [#sprintf] that makes you a float list of ascii codes.
Neither binary nor decimal representation is more precise than the other, it's just that their precision never matches exactly. 20 bits is slightly less than 6 decimals, whereas 16 decimals is slightly more than 53 bits. Thus you can only preserve precision by using slightly too many digits, otherwise you'll have too few.
I don't know what max5 does, but the only practical float sizes in the main processor are 24 bits and 53 bits. (this assumes that the most significant bit is not recorded because it's always one)
Which means, for example, in max you have more resolution than Pd to
control the playback of large arrays with precision (up to 2147483647,that's 31 bits. From 0 to 2147483647, you have 2147483648 numbers, which is pow(2,31) exactly (aka 1<<31), if it didn't overflow. the 32nd bit is the sign. That's using integers. I bet that you can't have integer signals. Can you ? Otherwise, you're stuck at the same limit as Pd... though Pd42 does offer a workaround as a 2nd inlet in [tabread~].
Does Max offer that 2nd inlet ?
don't know, can't even find out which object corresponds to tabread4~
BTW : in floats, pd can exactly represent powers of two up to pow(2,127). Powers of two are represented exactly in binary. They just won't be printed exactly in decimal by default, but [makefilename %f] can print «symbol 170141183460469231731687303715884105728.000000» accurately. The float format stops working just before getting to pow(2,128). But for [tabread~] you need contiguous integers, and that stops at 16777216, and for [tabread4~] you need at least some fractions to make it useful at all (contiguous sixteenths stop at 1048576, for example). So, your power-of-2 example is misleading in another way.
I already have an abstraction in pd to automatically set the offset to
play segments with tabread4~. But if I need e.g. to play indices 100000000
to 100000111, which are read from an array, and then rescaled in the
meantime, how is it possible to keep precision using symbol-tricks? The
2nd inlet doesn't help me much, if the numbers going inside are still
wrong.
Or, a concrete question: my table has 15312000 samples (5m19s@48K). You
mean that if I want to play from index 15311000 to 15312019, (these values
are read from a file and stored in an array, and also quantized in the
way), the precision will be correct, just will be printed wrongly in the
atom boxes?
Le 2012-01-13 à 16:10:00, João Pais a écrit :
I already have an abstraction in pd to automatically set the offset to play segments with tabread4~. But if I need e.g. to play indices 100000000 to 100000111, which are read from an array, and then rescaled in the meantime, how is it possible to keep precision using symbol-tricks?
No. A hundred million is already beyond capacity of the float32 format (in terms of contiguïty), anything made with text formats will get converted to float32 before they get used.
The 2nd inlet doesn't help me much, if the numbers going inside are still wrong.
What can I say... just don't make them wrong ! :}
Or, a concrete question: my table has 15312000 samples (5m19s@48K). You mean that if I want to play from index 15311000 to 15312019, (these values are read from a file and stored in an array, and also quantized in the way), the precision will be correct, just will be printed wrongly in the atom boxes?
For [tabread~], yes, because they're below 16777216.
For [tabread4~], it will be exactly like plain [tabread4~], because starting at half of 16777216, you don't have fractional indices anymore, and the whole point of [tabread4~] is to use fractional indices. For normal playback, [tabread~] is ok, but if you want to speed up or slow down the playback, you may need a few extra bits of precision to prevent certain artifacts.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Paywares or freeware same problem,
for example, you can not load more than 4g into RAM with ableton live because it's 32bit, also the error message for out memory only come with the last release, so live was crashing but without knowing what's happening during more than ten years. This problem didn't prevent live from being one of the most famous software, so this kind of limitation doesn't seem to be a valuable argument against programmes.
Colet Patrice
----- Mail original -----
De: "Mathieu Bouchard" matju@artengine.ca À: "João Pais" jmmmpais@googlemail.com Cc: "pd list" pd-list@iem.at, "Ben Baker-Smith" bbakersmith@gmail.com Envoyé: Vendredi 13 Janvier 2012 19:35:28 Objet: Re: [PD] no pd?? WTF ????
Le 2012-01-13 à 16:10:00, João Pais a écrit :
I already have an abstraction in pd to automatically set the offset to play segments with tabread4~. But if I need e.g. to play indices 100000000 to 100000111, which are read from an array, and then rescaled in the meantime, how is it possible to keep precision using symbol-tricks?
No. A hundred million is already beyond capacity of the float32 format (in terms of contiguïty), anything made with text formats will get converted to float32 before they get used.
The 2nd inlet doesn't help me much, if the numbers going inside are still wrong.
What can I say... just don't make them wrong ! :}
Or, a concrete question: my table has 15312000 samples (5m19s@48K). You mean that if I want to play from index 15311000 to 15312019, (these values are read from a file and stored in an array, and also quantized in the way), the precision will be correct, just will be printed wrongly in the atom boxes?
For [tabread~], yes, because they're below 16777216.
For [tabread4~], it will be exactly like plain [tabread4~], because starting at half of 16777216, you don't have fractional indices anymore, and the whole point of [tabread4~] is to use fractional indices. For normal playback, [tabread~] is ok, but if you want to speed up or slow down the playback, you may need a few extra bits of precision to prevent certain artifacts.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, | QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: João Pais jmmmpais@googlemail.com Cc: Max abonnements@revolwear.com; Jonathan Wilkes jancsika@yahoo.com; pd list pd-list@iem.at; Ben Baker-Smith bbakersmith@gmail.com Sent: Friday, January 13, 2012 1:35 PM Subject: Re: [PD] no pd?? WTF ????
Le 2012-01-13 à 16:10:00, João Pais a écrit :
I already have an abstraction in pd to automatically set the offset to play
segments with tabread4~. But if I need e.g. to play indices 100000000 to 100000111, which are read from an array, and then rescaled in the meantime, how is it possible to keep precision using symbol-tricks?
No. A hundred million is already beyond capacity of the float32 format (in terms of contiguïty), anything made with text formats will get converted to float32 before they get used.
The 2nd inlet doesn't help me much, if the numbers going inside are
still wrong.
What can I say... just don't make them wrong ! :}
Or, a concrete question: my table has 15312000 samples (5m19s@48K). You
mean that if I want to play from index 15311000 to 15312019, (these values are read from a file and stored in an array, and also quantized in the way), the precision will be correct, just will be printed wrongly in the atom boxes?
For [tabread~], yes, because they're below 16777216.
For [tabread4~], it will be exactly like plain [tabread4~], because starting at half of 16777216, you don't have fractional indices anymore, and the whole point of [tabread4~] is to use fractional indices. For normal playback, [tabread~] is ok, but if you want to speed up or slow down the playback, you may need a few extra bits of precision to prevent certain artifacts.
With Katja'sdouble-precision Pd does this problem go away?
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2012-01-13 à 11:14:00, Jonathan Wilkes a écrit :
From: Mathieu Bouchard matju@artengine.ca For [tabread~], yes, because they're below 16777216.
With Katja'sdouble-precision Pd does this problem go away?
If it does what I think it does, Katja's build reduces the problem by a factor of 536870912.
You can split that factor between increased table duration, increased table sampling rate, increased subsample resolution (tabread4), and increased waste of cpu watts. For all practical purposes, the 2nd-inlet hacks are also unnecessary, which reduces the complexity of tabread patches that access large tables, if they are made to rely on katja's build.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Hi,
João Pais wrote:
see how high you go with [expr pow(2,$f1)] until you loose resolution - 20 in pd, but 30 in max5 (the coming up of Pd double precision will help this, but it's a work Katja is doing alone).
High moral feeling (i.e. the "we're better because we're free" logo) isn't enough for precision dsp.
Ok, so what your're saying is that for closed software, users have to wait for the owner of the software to add some feature, while for open source software, users have the possibility to add whatever feature they want.
Both positions can take a while for a feature, so, what's your point ?
Try considering openness as a technical feature.
Cheers, Charlot
João Pais wrote:
see how high you go with [expr pow(2,$f1)] until you loose resolution - 20 in pd, but 30 in max5 (the coming up of Pd double precision will help this, but it's a work Katja is doing alone).
High moral feeling (i.e. the "we're better because we're free" logo) isn't enough for precision dsp.
Ok, so what your're saying is that for closed software, users have to wait for the owner of the software to add some feature, while for open source software, users have the possibility to add whatever feature they want.
I wasn't even going there, was speaking only about quality of performance.
Since you bring this topic in, you shouldn't say "users", because I (and
many people I know) can't do anything about improving the pd code until I
learn enough about C programming, and that won't be happening in this
life. In this case, "user" is the adequate name because she's working
alone (with help of others, but she's doing the work alone), and if this
user has better projects to develop, this feature won't go ahead.
And, in the way things are implemented, even if she manages to make double
versions of all branches of Pd (vanilla + ext in all build systems) and
maintain them in the next years, doesn't mean that this will ever caught
up in pd-core (pd-van) - looking at the current tradition, it will take a
long time.
Both positions can take a while for a feature, so, what's your point ?
Try considering openness as a technical feature.
I'm saying that just because the software is free/open, doesn't make it
better for one task than it's non-free partners (the inverse applies as
well, of course). And sometimes just saying "here it's better, because
there is no eye candy and people have to learn how to "really" program"
doesn't improve the quality of the program as a whole.
About "openness", I'm not interested in theoretical openness, because we
don't live in a theoretical world. Development depends on real people, and
if they can manage to allocate time and effort to create concrete things
(code, in this example). I'm sure there's lots of open code around svn or
other repositories which isn't going anywhere, openness isn't making it
develop itself.
Le 2012-01-11 à 13:09:00, Max a écrit :
And that's not the end of the vicious cycle. Students who saved their money to buy a Max license are often unwilling to accept that their work could have been done as easy in Pd, and sometimes even better and/or easier. Often they use and stick to Max simply because they have spent the money on it. They then keep paying for the updates. this is referred to as the concorde effect.
It's not just the money that you put on it, it's also the learning effort, and the effort of rebuilding the patches using slightly or not-so-slightly different components.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
"....> To avoid technical issues we choose the plattforms we already use in our work or we are very familiar with.
This is the only reason. If the selected composer can assure us to be available for the concert
the can be used any piece of software/hardware.
I hope this helps.
Many thanks"
Dagnabit! I wanted it to be an anti-libre conspiracy! This discussion has been wonderful nonetheless =)
On Wed, Jan 11, 2012 at 8:12 AM, Ben Baker-Smith bbakersmith@gmail.comwrote:
Hi list!
I got a more clear response from the organizers on this issue than anything I've seen in this thread so far - here it is:
Hi Ben,
thanks for your Interest in our Call.
We accepts only patches made with Kyma or Max/MSP due the fact we are
not able to provide
financial support for the two selected composers. So it is possible that
they will not be able to be in Milan for the concert.
To avoid technical issues we choose the plattforms we already use in our
work or we are very familiar with.
This is the only reason. If the selected composer can assure us to be available for the concert
the can be used any piece of software/hardware.
I hope this helps.
Many thanks
Federico Placidi
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Ben Baker-Smith -
Charles Goyard -
Hans-Christoph Steiner -
Jonathan Wilkes -
João Pais -
Martin Peach -
martin.peach＠sympatico.ca
-
Mathieu Bouchard -
Max -
Pagano, Patrick -
Patrice Colet -
Richie Cyngler