Re: [PD] audio bit resolution in Pd

[Alexandre Torres Porres]

According to Wikipedia

"as of 2007 digital audio converter technology is limited to a SNR of about
124 dB (21-bit) because of real-world limitations in integrated circuit
design. Still, this approximately matches the performance of the human
auditory system"

http://en.wikipedia.org/wiki/Audio_bit_depth#Floating_point

So, yeah, apparently there's no circuitry technology to go anywhere near 32
bit, so a 32 bit DAC seems weird and pointless...

I guess a good way to approach this issue I raised is to be able to define
what is the internal dynamic range in Pd for values between -1 and 1.

cheers

2015-04-23 15:02 GMT-03:00 Alexandre Torres Porres :

> WOW... I just learned something important! So, my whole point here was
> that I had the idea that DAWs like Ardour support 32-bit considering only
> values from -1 to 1. But that is just wrong!
>
> I just learned you can put a sound file with values in the hundreds /
> thousands in 32 bit float, load them into your DAW, and scale it down.
>
> I tried it by creating a sine wave in Pd with values from -100 to 100,
> exported as 32-bit float with writesf~, loaded into soundforge, then scaled
> it down 40 dB, and the sine wave was there!
>
> So yeah, Pd's audio resolution is the same as DAW which say they handle
> 32-bit float sound files. My whole issue was that Pd had a different way of
> dealing with 32-bit float, but not at all. In Principle, other softwares
> out there also deal with 32-bit float outside the boundaries of -1 to 1!!!
>
> That just answers my question then... once and for all and for good.
>
> I guess the discussion I ended up promoting is a parallel issue... let me
> rephrase it then.
>
> Regarding 24 bit DAC converters in sound cards, the 24 bits in there are
> just for values from -1 to 1, right?
>
> If so, then 32 bit float isn't really "8 more bits". And you've been also
> saying 24 bit converters are fixed, not float. So there's a weird
> relationship between this conversion from 32 bit float files to the
> soundcard.
>
> But then, I guess I'm happy with all I've learned so far.
>
> thanks
>
> 2015-04-23 13:26 GMT-03:00 Jamie Bullock :
>
>
>> On 22 April 2015 at 19:44:26, William Huston (williamahus...@gmail.com)
>> wrote:
>>
>> On Wednesday, April 22, 2015, Jamie Bullock 
>> wrote:
>> >
>> > Pd is 32-bit *floating point*, so you have 32-bit resolution between -1
>> and 1.
>>
>> I don't think that's right.
>>
>> The range of a single precision floating point number is from
>>
>> -3.4028234 × 10E38 to 3.4028234 × 10E38 (not from -1 to 1)
>>
>>
>> True, but I didn’t say the range of 32-bit float was -1 to 1!
>>
>> There are only 23 bits of precision for the mantissa + 1 for sign in a
>> single precision float.
>>
>>
>> Also true, but when I said “resolution” I didn’t mean “precision”.
>> Because the exponent can be negative, resolution scales dynamically from
>> 1..0 according to the value of the exponent, whilst precision stays fixed
>> according to the number of bits in the mantissa. Thus for very small values
>> the resolution (or quantisation step size) is far finer than can be
>> represented with the mantissa alone.
>>
>> What I was trying to put across (poorly!) in my original reply is that
>> unlike fixed point where for lower order values fewer bits are available in
>> the binary representation, with floating point, just because e.g. -1..1 is
>> a smaller range than -3.4 x 10E38..3.4 x 10E38 it doesn’t imply “fewer are
>> bits available”, e.g.
>>
>> Sign Exponent Mantissa
>> 0 0110   111 -> 0.9994
>> 0 0001 111 -> 2.3509886E-38
>> 1 010000 -> -1.0842022E-19
>> 1  0111000 -> -1.0
>>
>> Strictly speaking, I guess only 31 bits “count” in the range -1..1 due to
>> a maximum of 7-bits being significant in the exponent.
>>
>> best,
>>
>> Jamie
>>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Gem+v4l2loopback

[IOhannes m zmölnig]

On 04/23/2015 09:02 PM, Mario Mey wrote:
> El 23/04/15 a las 12:14, IOhannes m zmoelnig escibió:
>> On 2015-04-23 15:51, Mario Mey wrote:
>>> Well, I don't know if I was on 'video' group but I did the addition.  I
>>> checked the file you sent me and it works. However, for the moment, I
>>> have 3 questions:
>>>
>>> - If I don't activate the device in the right side of the patch, nor
>>> Blender nor VLC can get the image from /dev/video1 (VLC shows errors on
>>> console, Blender says nothing, but it makes black texture) Why is like
>>> that? Supposedly, being pix_record there and activated, I should get
>>> from where I want...
>> this could have a multitude of reasons.
>> i would suggest first checking what those errors are that VLC throws
>> (chances are they mean something).
>> then try using gstreamer(-0.10!) to display the video. something like:
>>$ gst-launch0.10 v4l2src device=/dev/video1 ! ffmpegcolorspace !
>> xvimagesink
>
> After some tests (including using gst-launch0.10)... I realized that I
> was wrong. Blender and VLC can read from /dev/video1 without activating
> it on Pd.

unfortunately i don't know what you mean exactly with "activating".


> 
> But... I need to create gemwin before VLC or Blender or Gstreamer. Is
> this normal? Should I need gem window opened? It is for gemhead to make
> gemlists... isn't it?


and you need gemlists for pix sources to emit pixel data.
and you need pixel data for [pix_record] to set the output frame
dimensions/colorspace.
and you need to set the output frame dimensions/colorspace in order to
turn a v4l2loopback OUTPUT device into a CAPTURE device.
and you need a CAPTURE device in order to read it in blender, vlc,... or
any other capturing application.

>>
>> anyhow, this means that the v4l2loopback output is working.
>> so that leaves two more potential candidates for your*problem*:
> Do you mean the Blender and VLC getting "problem"? It is resolved.
> Well... maybe it never was there.
>> - the v4l2loopback kernel module (there are some known issues with e.g.
>> gstreamer-1.0; which version are you using?)

> I didn't know I had gstreamer installed on the system. I have 1.0 and 0.10.

i was referring to the version of v4l2loopback.
sorry for the confusion.



fngsrd
IOhannes



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

Re: [PD] Gem+v4l2loopback (was Re: pdp_vloopback ?)

[Mario Mey]

At the end, I'm telling a bug...

El 23/04/15 a las 12:14, IOhannes m zmoelnig escibió:

On 2015-04-23 15:51, Mario Mey wrote:

Well, I don't know if I was on 'video' group but I did the addition.  I
checked the file you sent me and it works. However, for the moment, I
have 3 questions:

- If I don't activate the device in the right side of the patch, nor
Blender nor VLC can get the image from /dev/video1 (VLC shows errors on
console, Blender says nothing, but it makes black texture) Why is like
that? Supposedly, being pix_record there and activated, I should get
from where I want...

this could have a multitude of reasons.
i would suggest first checking what those errors are that VLC throws
(chances are they mean something).
then try using gstreamer(-0.10!) to display the video. something like:
   $ gst-launch0.10 v4l2src device=/dev/video1 ! ffmpegcolorspace !
xvimagesink
After some tests (including using gst-launch0.10)... I realized that I 
was wrong. Blender and VLC can read from /dev/video1 without activating 
it on Pd.


But... I need to create gemwin before VLC or Blender or Gstreamer. Is 
this normal? Should I need gem window opened? It is for gemhead to make 
gemlists... isn't it?



- Look at the attached image: why the video is vertically inverted? I
don't know about GEM, but I didn't find any object that do that.

it's the olde discrepancy between openGL image coordinates (starting in
the lower left corner) and most other pixel coordinates (starting in the
upper left corner), and a small bug in the old recordV4L2 implementation
of Gem (which should be fixed in recent git).
iirc putting a [pix_flip] before [pix_record] might fix the problem.

[pix_flip] does the trick.


anyhow, this means that the v4l2loopback output is working.
so that leaves two more potential candidates for your*problem*:
Do you mean the Blender and VLC getting "problem"? It is resolved. 
Well... maybe it never was there.

- the v4l2loopback kernel module (there are some known issues with e.g.
gstreamer-1.0; which version are you using?)

I didn't know I had gstreamer installed on the system. I have 1.0 and 0.10.

- the consumer applications (blender/vlc): while working on the
v4l2loopback module i noticed that quite a number of v4l2 applications
make unjustified assumptions about the v4l2 device, which sometimes are
not satisfied by v4l2loopback. (like refusing to work when the card_name
does not match the device-name...)

Blender and VLC get the video correctly.



- How the patch should be if I want to send the GEM window to loopback?
I mean, not only the color and vertical inverted video, but the whole
window...

checkout [pix_snap] to fetch a framebuffer into pixes.

I'll check it later.

fgasm
IOhannes


Using the patch from Antoine, when I click in [device /dev/video1( from 
the right side of the patch, the rectangle with the video appears. But 
when I try to close Pd, it freezes. I have to kill it. I tried some 
things with no success:


- Remove pix_record before closing
- Send record 0 to pix_record before closing.

Is this a bug?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Tcl error with [cursor], [mousestate], [receivecanvas]

[rolfm]

Hi ,

i hope somebody can say something about the following:

in Pdext 43.4 in Windows 7 [cursor], [mousestate],[receivecanvas] generate a
Tcl error on click, which doesn't happen with Pdext 42.5.

(Tcl) UNHANDLED ERROR: extra characters after close-quote
while executing
"pdsend "#38fda78 motion [winfo pointerxy ]".x38a1060.citemconfigure  
396c370BUT -fill #00fc04"


("uplevel"body line 2)
invoked from within
"uplevel #0 $cmds_from_pd"

is this a bug?
or is there some change involved i don't know about?

thanks in advance,
rolf




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

Re: [PD] PD install on a raspberry pi 2

[IOhannes m zmölnig]

On 04/23/2015 08:12 PM, lhanneuse puredata wrote:
> Hi,
> Can somebody help me to install PD on a raspberry pi 2.
> I've a fresh sd-card with raspbian.
> 
> How do I get the source-code of PD ?
> Then how do I build it ?

aptitude install puredata

gfmasrd
IOhannes




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

[PD] PD install on a raspberry pi 2

[lhanneuse puredata]

Hi,
Can somebody help me to install PD on a raspberry pi 2.
I've a fresh sd-card with raspbian.

How do I get the source-code of PD ?
Then how do I build it ?

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

Re: [PD] audio bit resolution in Pd

[Alexandre Torres Porres]

WOW... I just learned something important! So, my whole point here was that I
had the idea that DAWs like Ardour support 32-bit considering only values
from -1 to 1. But that is just wrong!

I just learned you can put a sound file with values in the hundreds /
thousands in 32 bit float, load them into your DAW, and scale it down.

I tried it by creating a sine wave in Pd with values from -100 to 100,
exported as 32-bit float with writesf~, loaded into soundforge, then scaled
it down 40 dB, and the sine wave was there!

So yeah, Pd's audio resolution is the same as DAW which say they handle
32-bit float sound files. My whole issue was that Pd had a different way of
dealing with 32-bit float, but not at all. In Principle, other softwares
out there also deal with 32-bit float outside the boundaries of -1 to 1!!!

That just answers my question then... once and for all and for good.

I guess the discussion I ended up promoting is a parallel issue... let me
rephrase it then.

Regarding 24 bit DAC converters in sound cards, the 24 bits in there are
just for values from -1 to 1, right?

If so, then 32 bit float isn't really "8 more bits". And you've been also
saying 24 bit converters are fixed, not float. So there's a weird
relationship between this conversion from 32 bit float files to the
soundcard.

But then, I guess I'm happy with all I've learned so far.

thanks

2015-04-23 13:26 GMT-03:00 Jamie Bullock :

>
> On 22 April 2015 at 19:44:26, William Huston (williamahus...@gmail.com)
> wrote:
>
> On Wednesday, April 22, 2015, Jamie Bullock 
> wrote:
> >
> > Pd is 32-bit *floating point*, so you have 32-bit resolution between -1
> and 1.
>
> I don't think that's right.
>
> The range of a single precision floating point number is from
>
> -3.4028234 × 10E38 to 3.4028234 × 10E38 (not from -1 to 1)
>
>
> True, but I didn’t say the range of 32-bit float was -1 to 1!
>
> There are only 23 bits of precision for the mantissa + 1 for sign in a
> single precision float.
>
>
> Also true, but when I said “resolution” I didn’t mean “precision”. Because
> the exponent can be negative, resolution scales dynamically from 1..0
> according to the value of the exponent, whilst precision stays fixed
> according to the number of bits in the mantissa. Thus for very small values
> the resolution (or quantisation step size) is far finer than can be
> represented with the mantissa alone.
>
> What I was trying to put across (poorly!) in my original reply is that
> unlike fixed point where for lower order values fewer bits are available in
> the binary representation, with floating point, just because e.g. -1..1 is
> a smaller range than -3.4 x 10E38..3.4 x 10E38 it doesn’t imply “fewer are
> bits available”, e.g.
>
> Sign Exponent Mantissa
> 0 0110   111 -> 0.9994
> 0 0001 111 -> 2.3509886E-38
> 1 010000 -> -1.0842022E-19
> 1  0111000 -> -1.0
>
> Strictly speaking, I guess only 31 bits “count” in the range -1..1 due to
> a maximum of 7-bits being significant in the exponent.
>
> best,
>
> Jamie
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] audio bit resolution in Pd

[Jamie Bullock]

On 22 April 2015 at 19:44:26, William Huston (williamahus...@gmail.com) wrote:

On Wednesday, April 22, 2015, Jamie Bullock  wrote:
>
> Pd is 32-bit *floating point*, so you have 32-bit resolution between -1 and 1.

I don't think that's right.

The range of a single precision floating point number is from

-3.4028234 × 10E38 to 3.4028234 × 10E38 (not from -1 to 1)


True, but I didn’t say the range of 32-bit float was -1 to 1!

There are only 23 bits of precision for the mantissa + 1 for sign in a single 
precision float.


Also true, but when I said “resolution” I didn’t mean “precision”. Because the 
exponent can be negative, resolution scales dynamically from 1..0 according to 
the value of the exponent, whilst precision stays fixed according to the number 
of bits in the mantissa. Thus for very small values the resolution (or 
quantisation step size) is far finer than can be represented with the mantissa 
alone. 

What I was trying to put across (poorly!) in my original reply is that unlike 
fixed point where for lower order values fewer bits are available in the binary 
representation, with floating point, just because e.g. -1..1 is a smaller range 
than -3.4 x 10E38..3.4 x 10E38 it doesn’t imply “fewer are bits available”, e.g.

SignExponentMantissa
0   0110    111 -> 0.9994
0   0001111 -> 2.3509886E-38
1   0100        00  -> -1.0842022E-19
1              01110        00  -> -1.0

Strictly speaking, I guess only 31 bits “count” in the range -1..1 due to a 
maximum of 7-bits being significant in the exponent.

best,

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

Re: [PD] audio bit resolution in Pd

[Cyrille Henry]

Le 23/04/2015 17:25, Miller Puckette a écrit :

I get 1 000 000 = 2^19.9 so a 20 bit dynamic range.

yes, your right,
thanks for the correction
c



I don't think A/D/A hardware ever gets better than about 110 dB dtnamic
range though.

cheers
Miller

On Thu, Apr 23, 2015 at 05:20:51PM +0200, Cyrille Henry wrote:



Le 23/04/2015 16:41, Alexandre Torres Porres a écrit :

Yep, nice indeed, I guess I learned - in short and in layman's undetailed terms 
- that audio output is ~24bits (a bit higher, but much higher for smaller 
numbers).

Moreover, digital audio cards won't likely have more than 24 bit precision for 
many years to come, so it's just way more than enough.

The human ear is usually consider to be sensible from 0dB to 120dB, so a range 
of 10^(12/2) between the smallest and biggest amplitude.
i.e from 1 to 1 000 000, or from 1 to 2^13.8
so, the human ear sensitivity can be considered to be about 14 bits.
16 bits diffusion should be enough.
24 bits diffusion is already overkill.

cheers
c



thanks


2015-04-23 6:43 GMT-03:00 Julian Brooks mailto:jbee...@gmail.com>>:

Nice. Thanks Chuck, I learnt something.

On 22 April 2015 at 23:45, Charles Z Henry mailto:czhe...@gmail.com>> wrote:

On Wed, Apr 22, 2015 at 5:11 PM, Alexandre Torres Porres
mailto:por...@gmail.com>> wrote:

> So I start with this idea that the audio (values from -1 to 1) can't 
be in
> full 32 bit float resolution, it's less. I don't see why that is 
"wrong".
> And then, from it, my first question here was: "what is the audio 
resolution
> then?". I'm still clueless here about this answer.
>
> Moreover, is it more or less than what 24 bit audio cards handle?

Let me try:

32-bit floating point numbers have 24 bits of precision.  Always.  The
remaining 8 bits are just for the sign and exponent.  When the
amplitude of the signals decrease, you don't lose any precision in
floating-point.  The value of the least significant bit (LSB) gets
proportionally smaller.

However, the output of a 24-bit soundcard always has a fixed
quantization.  The LSB is always the same size.  Smaller numbers have
less precision.

The mismatch occurs when converting from the 32-bit floats to the
24-bit fixed point numbers.  Now, the smaller numbers aren't as
precise anymore.  They get rounded to the nearest number in the 24-bit
fixed point system.

So, yes, the resolution (of small numbers) in floating point (internal
to Pd) is finer than the resolution of those numbers when output
(driver/DAC).

Also, the 24-bit fixed point format is for values between -1 and 1.
That means that numbers between 0 and 1 have just 23 bits.  In 32-bit
math, the numbers between 0.5 and 1 still have 24 bits of precision
(the sign is held elsewhere).  That means that Pd's internal
resolution is finer than the soundcard resolution for all numbers
between -1 and 1.

Chuck

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





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



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




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

Re: [PD] audio bit resolution in Pd

[Alexandre Torres Porres]

> Chuck made me think it was a bit more than 24 bits,
> now it seems Miller says it's more likely to be 20 bits :)

or I just got that way wrong and miller wasn't talking about this at all...
so I stick to chuck's answer.

cheers

2015-04-23 12:55 GMT-03:00 Alexandre Torres Porres :

> I know there's a parallel discussion about human hearing and what audio
> cards can get there. But I'm just trying to get one simple fact clear, that
> is the bit depth of audio in Pd :)
>
> Leaving the human hearing or audio cards aside, some DAW (like Pro Tools
> or Ardour) do operate on audio files that are actual 32 bit resolution. I
> guess the idea is to keep quantization error as low as possible when
> mixing, normalizing, processing, filtering, mastering and everything. Then
> you can convert it to, say, 24 bit high quality audio afterwards for
> distribution - I guess this is the standard for highest digital audio these
> days, meaning that it's pointless to have a final audio that's higher than
> that, but then, 32 bit dac seem to be showing up already as chuck pointed
> out, but I digress. Moreover, you can also convert it to 16 bit CD quality
> afterwards, or even just make some MP3 or whatever...
>
> Not to get into the discussion if dealing with 32 bits internally on a DAW
> is really important or worth the hassle (and not even getting into the deal
> with new 32 bit dac), the fact is that 32 bit audio exists out there for
> some time now. They do have this 32 bits option, or even more maybe... (not
> sure if they're pushing it to 64 yet, but it doesn't matter).
>
> So, I always knew Pd was "32 bit", and knowing the above, I was misled to
> think Pd was just like Pro Tools or Ardour, that it could process audio in
> 32 bit. But I was thinking about it these days and it hit me that you just
> can't say Pd processes audio like Ardour and Pro Tools do on 32 bit
> precision.
>
> Bottom line, you can't!
>
> So this made me wonder what the heck that precision would be...
>
> Chuck made me think it was a bit more than 24 bits, now it seems Miller
> says it's more likely to be 20 bits :)
>
> cheers
>
>
>
> 2015-04-23 12:25 GMT-03:00 Miller Puckette :
>
> I get 1 000 000 = 2^19.9 so a 20 bit dynamic range.
>>
>> I don't think A/D/A hardware ever gets better than about 110 dB dtnamic
>> range though.
>>
>> cheers
>> Miller
>>
>> On Thu, Apr 23, 2015 at 05:20:51PM +0200, Cyrille Henry wrote:
>> >
>> >
>> > Le 23/04/2015 16:41, Alexandre Torres Porres a écrit :
>> > >Yep, nice indeed, I guess I learned - in short and in layman's
>> undetailed terms - that audio output is ~24bits (a bit higher, but much
>> higher for smaller numbers).
>> > >
>> > >Moreover, digital audio cards won't likely have more than 24 bit
>> precision for many years to come, so it's just way more than enough.
>> > The human ear is usually consider to be sensible from 0dB to 120dB, so
>> a range of 10^(12/2) between the smallest and biggest amplitude.
>> > i.e from 1 to 1 000 000, or from 1 to 2^13.8
>> > so, the human ear sensitivity can be considered to be about 14 bits.
>> > 16 bits diffusion should be enough.
>> > 24 bits diffusion is already overkill.
>> >
>> > cheers
>> > c
>> >
>> > >
>> > >thanks
>> > >
>> > >
>> > >2015-04-23 6:43 GMT-03:00 Julian Brooks > jbee...@gmail.com>>:
>> > >
>> > >Nice. Thanks Chuck, I learnt something.
>> > >
>> > >On 22 April 2015 at 23:45, Charles Z Henry > > wrote:
>> > >
>> > >On Wed, Apr 22, 2015 at 5:11 PM, Alexandre Torres Porres
>> > >mailto:por...@gmail.com>> wrote:
>> > >
>> > >> So I start with this idea that the audio (values from -1 to
>> 1) can't be in
>> > >> full 32 bit float resolution, it's less. I don't see why
>> that is "wrong".
>> > >> And then, from it, my first question here was: "what is the
>> audio resolution
>> > >> then?". I'm still clueless here about this answer.
>> > >>
>> > >> Moreover, is it more or less than what 24 bit audio cards
>> handle?
>> > >
>> > >Let me try:
>> > >
>> > >32-bit floating point numbers have 24 bits of precision.
>> Always.  The
>> > >remaining 8 bits are just for the sign and exponent.  When the
>> > >amplitude of the signals decrease, you don't lose any
>> precision in
>> > >floating-point.  The value of the least significant bit (LSB)
>> gets
>> > >proportionally smaller.
>> > >
>> > >However, the output of a 24-bit soundcard always has a fixed
>> > >quantization.  The LSB is always the same size.  Smaller
>> numbers have
>> > >less precision.
>> > >
>> > >The mismatch occurs when converting from the 32-bit floats to
>> the
>> > >24-bit fixed point numbers.  Now, the smaller numbers aren't as
>> > >precise anymore.  They get rounded to the nearest number in
>> the 24-bit
>> > >fixed point system.
>> > >
>> > >So, yes, the resolution (of small numbers)

Re: [PD] audio bit resolution in Pd

[Alexandre Torres Porres]

I know there's a parallel discussion about human hearing and what audio
cards can get there. But I'm just trying to get one simple fact clear, that
is the bit depth of audio in Pd :)

Leaving the human hearing or audio cards aside, some DAW (like Pro Tools or
Ardour) do operate on audio files that are actual 32 bit resolution. I
guess the idea is to keep quantization error as low as possible when
mixing, normalizing, processing, filtering, mastering and everything. Then
you can convert it to, say, 24 bit high quality audio afterwards for
distribution - I guess this is the standard for highest digital audio these
days, meaning that it's pointless to have a final audio that's higher than
that, but then, 32 bit dac seem to be showing up already as chuck pointed
out, but I digress. Moreover, you can also convert it to 16 bit CD quality
afterwards, or even just make some MP3 or whatever...

Not to get into the discussion if dealing with 32 bits internally on a DAW
is really important or worth the hassle (and not even getting into the deal
with new 32 bit dac), the fact is that 32 bit audio exists out there for
some time now. They do have this 32 bits option, or even more maybe... (not
sure if they're pushing it to 64 yet, but it doesn't matter).

So, I always knew Pd was "32 bit", and knowing the above, I was misled to
think Pd was just like Pro Tools or Ardour, that it could process audio in
32 bit. But I was thinking about it these days and it hit me that you just
can't say Pd processes audio like Ardour and Pro Tools do on 32 bit
precision.

Bottom line, you can't!

So this made me wonder what the heck that precision would be...

Chuck made me think it was a bit more than 24 bits, now it seems Miller
says it's more likely to be 20 bits :)

cheers



2015-04-23 12:25 GMT-03:00 Miller Puckette :

> I get 1 000 000 = 2^19.9 so a 20 bit dynamic range.
>
> I don't think A/D/A hardware ever gets better than about 110 dB dtnamic
> range though.
>
> cheers
> Miller
>
> On Thu, Apr 23, 2015 at 05:20:51PM +0200, Cyrille Henry wrote:
> >
> >
> > Le 23/04/2015 16:41, Alexandre Torres Porres a écrit :
> > >Yep, nice indeed, I guess I learned - in short and in layman's
> undetailed terms - that audio output is ~24bits (a bit higher, but much
> higher for smaller numbers).
> > >
> > >Moreover, digital audio cards won't likely have more than 24 bit
> precision for many years to come, so it's just way more than enough.
> > The human ear is usually consider to be sensible from 0dB to 120dB, so a
> range of 10^(12/2) between the smallest and biggest amplitude.
> > i.e from 1 to 1 000 000, or from 1 to 2^13.8
> > so, the human ear sensitivity can be considered to be about 14 bits.
> > 16 bits diffusion should be enough.
> > 24 bits diffusion is already overkill.
> >
> > cheers
> > c
> >
> > >
> > >thanks
> > >
> > >
> > >2015-04-23 6:43 GMT-03:00 Julian Brooks  jbee...@gmail.com>>:
> > >
> > >Nice. Thanks Chuck, I learnt something.
> > >
> > >On 22 April 2015 at 23:45, Charles Z Henry  > wrote:
> > >
> > >On Wed, Apr 22, 2015 at 5:11 PM, Alexandre Torres Porres
> > >mailto:por...@gmail.com>> wrote:
> > >
> > >> So I start with this idea that the audio (values from -1 to
> 1) can't be in
> > >> full 32 bit float resolution, it's less. I don't see why that
> is "wrong".
> > >> And then, from it, my first question here was: "what is the
> audio resolution
> > >> then?". I'm still clueless here about this answer.
> > >>
> > >> Moreover, is it more or less than what 24 bit audio cards
> handle?
> > >
> > >Let me try:
> > >
> > >32-bit floating point numbers have 24 bits of precision.
> Always.  The
> > >remaining 8 bits are just for the sign and exponent.  When the
> > >amplitude of the signals decrease, you don't lose any precision
> in
> > >floating-point.  The value of the least significant bit (LSB)
> gets
> > >proportionally smaller.
> > >
> > >However, the output of a 24-bit soundcard always has a fixed
> > >quantization.  The LSB is always the same size.  Smaller
> numbers have
> > >less precision.
> > >
> > >The mismatch occurs when converting from the 32-bit floats to
> the
> > >24-bit fixed point numbers.  Now, the smaller numbers aren't as
> > >precise anymore.  They get rounded to the nearest number in the
> 24-bit
> > >fixed point system.
> > >
> > >So, yes, the resolution (of small numbers) in floating point
> (internal
> > >to Pd) is finer than the resolution of those numbers when output
> > >(driver/DAC).
> > >
> > >Also, the 24-bit fixed point format is for values between -1
> and 1.
> > >That means that numbers between 0 and 1 have just 23 bits.  In
> 32-bit
> > >math, the numbers between 0.5 and 1 still have 24 bits of
> precision
> > >(the sign is held elsewhe

Re: [PD] audio bit resolution in Pd

[Alexandre Torres Porres]

What? 32Bit 384KHz dac? And for 50 bucks? what the $*#%@?

2015-04-23 12:43 GMT-03:00 Charles Z Henry :

> It's already started 32bit DACs are available from AKM and XMOS,
> for example.  Although I don't know what software/hardware platform
> you'd use to actually make use of this precision, you can build your
> own 32-bit sound playback interface with a few boards from HK:
>
> http://www.yuan-jing.com/dacs-decoder/32bit-192khz-usb-dac-decoder-ak4399-wm8805-pcm2706-opa627au-optical-coaxial
>
> http://www.yuan-jing.com/dacs-decoder/xmos-usb-audio-32bit-384khz-dac-decoder-board-pcm5102-tda1308-headphone-amp
>
>
> On Thu, Apr 23, 2015 at 9:41 AM, Alexandre Torres Porres
>  wrote:
> > Yep, nice indeed, I guess I learned - in short and in layman's undetailed
> > terms - that audio output is ~24bits (a bit higher, but much higher for
> > smaller numbers).
> >
> > Moreover, digital audio cards won't likely have more than 24 bit
> precision
> > for many years to come, so it's just way more than enough.
> >
> > thanks
> >
> >
> > 2015-04-23 6:43 GMT-03:00 Julian Brooks :
> >
> >> Nice. Thanks Chuck, I learnt something.
> >>
> >> On 22 April 2015 at 23:45, Charles Z Henry  wrote:
> >>>
> >>> On Wed, Apr 22, 2015 at 5:11 PM, Alexandre Torres Porres
> >>>  wrote:
> >>>
> >>> > So I start with this idea that the audio (values from -1 to 1) can't
> be
> >>> > in
> >>> > full 32 bit float resolution, it's less. I don't see why that is
> >>> > "wrong".
> >>> > And then, from it, my first question here was: "what is the audio
> >>> > resolution
> >>> > then?". I'm still clueless here about this answer.
> >>> >
> >>> > Moreover, is it more or less than what 24 bit audio cards handle?
> >>>
> >>> Let me try:
> >>>
> >>> 32-bit floating point numbers have 24 bits of precision.  Always.  The
> >>> remaining 8 bits are just for the sign and exponent.  When the
> >>> amplitude of the signals decrease, you don't lose any precision in
> >>> floating-point.  The value of the least significant bit (LSB) gets
> >>> proportionally smaller.
> >>>
> >>> However, the output of a 24-bit soundcard always has a fixed
> >>> quantization.  The LSB is always the same size.  Smaller numbers have
> >>> less precision.
> >>>
> >>> The mismatch occurs when converting from the 32-bit floats to the
> >>> 24-bit fixed point numbers.  Now, the smaller numbers aren't as
> >>> precise anymore.  They get rounded to the nearest number in the 24-bit
> >>> fixed point system.
> >>>
> >>> So, yes, the resolution (of small numbers) in floating point (internal
> >>> to Pd) is finer than the resolution of those numbers when output
> >>> (driver/DAC).
> >>>
> >>> Also, the 24-bit fixed point format is for values between -1 and 1.
> >>> That means that numbers between 0 and 1 have just 23 bits.  In 32-bit
> >>> math, the numbers between 0.5 and 1 still have 24 bits of precision
> >>> (the sign is held elsewhere).  That means that Pd's internal
> >>> resolution is finer than the soundcard resolution for all numbers
> >>> between -1 and 1.
> >>>
> >>> Chuck
> >>>
> >>> ___
> >>> Pd-list@lists.iem.at mailing list
> >>> UNSUBSCRIBE and account-management ->
> >>> http://lists.puredata.info/listinfo/pd-list
> >>
> >>
> >
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] audio bit resolution in Pd

[Charles Z Henry]

It's already started 32bit DACs are available from AKM and XMOS,
for example.  Although I don't know what software/hardware platform
you'd use to actually make use of this precision, you can build your
own 32-bit sound playback interface with a few boards from HK:
http://www.yuan-jing.com/dacs-decoder/32bit-192khz-usb-dac-decoder-ak4399-wm8805-pcm2706-opa627au-optical-coaxial
http://www.yuan-jing.com/dacs-decoder/xmos-usb-audio-32bit-384khz-dac-decoder-board-pcm5102-tda1308-headphone-amp


On Thu, Apr 23, 2015 at 9:41 AM, Alexandre Torres Porres
 wrote:
> Yep, nice indeed, I guess I learned - in short and in layman's undetailed
> terms - that audio output is ~24bits (a bit higher, but much higher for
> smaller numbers).
>
> Moreover, digital audio cards won't likely have more than 24 bit precision
> for many years to come, so it's just way more than enough.
>
> thanks
>
>
> 2015-04-23 6:43 GMT-03:00 Julian Brooks :
>
>> Nice. Thanks Chuck, I learnt something.
>>
>> On 22 April 2015 at 23:45, Charles Z Henry  wrote:
>>>
>>> On Wed, Apr 22, 2015 at 5:11 PM, Alexandre Torres Porres
>>>  wrote:
>>>
>>> > So I start with this idea that the audio (values from -1 to 1) can't be
>>> > in
>>> > full 32 bit float resolution, it's less. I don't see why that is
>>> > "wrong".
>>> > And then, from it, my first question here was: "what is the audio
>>> > resolution
>>> > then?". I'm still clueless here about this answer.
>>> >
>>> > Moreover, is it more or less than what 24 bit audio cards handle?
>>>
>>> Let me try:
>>>
>>> 32-bit floating point numbers have 24 bits of precision.  Always.  The
>>> remaining 8 bits are just for the sign and exponent.  When the
>>> amplitude of the signals decrease, you don't lose any precision in
>>> floating-point.  The value of the least significant bit (LSB) gets
>>> proportionally smaller.
>>>
>>> However, the output of a 24-bit soundcard always has a fixed
>>> quantization.  The LSB is always the same size.  Smaller numbers have
>>> less precision.
>>>
>>> The mismatch occurs when converting from the 32-bit floats to the
>>> 24-bit fixed point numbers.  Now, the smaller numbers aren't as
>>> precise anymore.  They get rounded to the nearest number in the 24-bit
>>> fixed point system.
>>>
>>> So, yes, the resolution (of small numbers) in floating point (internal
>>> to Pd) is finer than the resolution of those numbers when output
>>> (driver/DAC).
>>>
>>> Also, the 24-bit fixed point format is for values between -1 and 1.
>>> That means that numbers between 0 and 1 have just 23 bits.  In 32-bit
>>> math, the numbers between 0.5 and 1 still have 24 bits of precision
>>> (the sign is held elsewhere).  That means that Pd's internal
>>> resolution is finer than the soundcard resolution for all numbers
>>> between -1 and 1.
>>>
>>> Chuck
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>

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

Re: [PD] audio bit resolution in Pd

[Miller Puckette]

I get 1 000 000 = 2^19.9 so a 20 bit dynamic range.

I don't think A/D/A hardware ever gets better than about 110 dB dtnamic
range though.

cheers
Miller

On Thu, Apr 23, 2015 at 05:20:51PM +0200, Cyrille Henry wrote:
> 
> 
> Le 23/04/2015 16:41, Alexandre Torres Porres a écrit :
> >Yep, nice indeed, I guess I learned - in short and in layman's undetailed 
> >terms - that audio output is ~24bits (a bit higher, but much higher for 
> >smaller numbers).
> >
> >Moreover, digital audio cards won't likely have more than 24 bit precision 
> >for many years to come, so it's just way more than enough.
> The human ear is usually consider to be sensible from 0dB to 120dB, so a 
> range of 10^(12/2) between the smallest and biggest amplitude.
> i.e from 1 to 1 000 000, or from 1 to 2^13.8
> so, the human ear sensitivity can be considered to be about 14 bits.
> 16 bits diffusion should be enough.
> 24 bits diffusion is already overkill.
> 
> cheers
> c
> 
> >
> >thanks
> >
> >
> >2015-04-23 6:43 GMT-03:00 Julian Brooks  >>:
> >
> >Nice. Thanks Chuck, I learnt something.
> >
> >On 22 April 2015 at 23:45, Charles Z Henry  > > wrote:
> >
> >On Wed, Apr 22, 2015 at 5:11 PM, Alexandre Torres Porres
> >mailto:por...@gmail.com>> wrote:
> >
> >> So I start with this idea that the audio (values from -1 to 1) 
> > can't be in
> >> full 32 bit float resolution, it's less. I don't see why that is 
> > "wrong".
> >> And then, from it, my first question here was: "what is the audio 
> > resolution
> >> then?". I'm still clueless here about this answer.
> >>
> >> Moreover, is it more or less than what 24 bit audio cards handle?
> >
> >Let me try:
> >
> >32-bit floating point numbers have 24 bits of precision.  Always.  
> > The
> >remaining 8 bits are just for the sign and exponent.  When the
> >amplitude of the signals decrease, you don't lose any precision in
> >floating-point.  The value of the least significant bit (LSB) gets
> >proportionally smaller.
> >
> >However, the output of a 24-bit soundcard always has a fixed
> >quantization.  The LSB is always the same size.  Smaller numbers have
> >less precision.
> >
> >The mismatch occurs when converting from the 32-bit floats to the
> >24-bit fixed point numbers.  Now, the smaller numbers aren't as
> >precise anymore.  They get rounded to the nearest number in the 
> > 24-bit
> >fixed point system.
> >
> >So, yes, the resolution (of small numbers) in floating point 
> > (internal
> >to Pd) is finer than the resolution of those numbers when output
> >(driver/DAC).
> >
> >Also, the 24-bit fixed point format is for values between -1 and 1.
> >That means that numbers between 0 and 1 have just 23 bits.  In 32-bit
> >math, the numbers between 0.5 and 1 still have 24 bits of precision
> >(the sign is held elsewhere).  That means that Pd's internal
> >resolution is finer than the soundcard resolution for all numbers
> >between -1 and 1.
> >
> >Chuck
> >
> >___
> >Pd-list@lists.iem.at  mailing list
> >UNSUBSCRIBE and account-management -> 
> > http://lists.puredata.info/listinfo/pd-list
> >
> >
> >
> >
> >
> >___
> >Pd-list@lists.iem.at mailing list
> >UNSUBSCRIBE and account-management -> 
> >http://lists.puredata.info/listinfo/pd-list
> >
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

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

Re: [PD] audio bit resolution in Pd

[Cyrille Henry]

Le 23/04/2015 16:41, Alexandre Torres Porres a écrit :

Yep, nice indeed, I guess I learned - in short and in layman's undetailed terms 
- that audio output is ~24bits (a bit higher, but much higher for smaller 
numbers).

Moreover, digital audio cards won't likely have more than 24 bit precision for 
many years to come, so it's just way more than enough.

The human ear is usually consider to be sensible from 0dB to 120dB, so a range 
of 10^(12/2) between the smallest and biggest amplitude.
i.e from 1 to 1 000 000, or from 1 to 2^13.8
so, the human ear sensitivity can be considered to be about 14 bits.
16 bits diffusion should be enough.
24 bits diffusion is already overkill.

cheers
c



thanks


2015-04-23 6:43 GMT-03:00 Julian Brooks mailto:jbee...@gmail.com>>:

Nice. Thanks Chuck, I learnt something.

On 22 April 2015 at 23:45, Charles Z Henry mailto:czhe...@gmail.com>> wrote:

On Wed, Apr 22, 2015 at 5:11 PM, Alexandre Torres Porres
mailto:por...@gmail.com>> wrote:

> So I start with this idea that the audio (values from -1 to 1) can't 
be in
> full 32 bit float resolution, it's less. I don't see why that is 
"wrong".
> And then, from it, my first question here was: "what is the audio 
resolution
> then?". I'm still clueless here about this answer.
>
> Moreover, is it more or less than what 24 bit audio cards handle?

Let me try:

32-bit floating point numbers have 24 bits of precision.  Always.  The
remaining 8 bits are just for the sign and exponent.  When the
amplitude of the signals decrease, you don't lose any precision in
floating-point.  The value of the least significant bit (LSB) gets
proportionally smaller.

However, the output of a 24-bit soundcard always has a fixed
quantization.  The LSB is always the same size.  Smaller numbers have
less precision.

The mismatch occurs when converting from the 32-bit floats to the
24-bit fixed point numbers.  Now, the smaller numbers aren't as
precise anymore.  They get rounded to the nearest number in the 24-bit
fixed point system.

So, yes, the resolution (of small numbers) in floating point (internal
to Pd) is finer than the resolution of those numbers when output
(driver/DAC).

Also, the 24-bit fixed point format is for values between -1 and 1.
That means that numbers between 0 and 1 have just 23 bits.  In 32-bit
math, the numbers between 0.5 and 1 still have 24 bits of precision
(the sign is held elsewhere).  That means that Pd's internal
resolution is finer than the soundcard resolution for all numbers
between -1 and 1.

Chuck

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





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



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

Re: [PD] Gem+v4l2loopback (was Re: pdp_vloopback ?)

[IOhannes m zmoelnig]

On 2015-04-23 15:51, Mario Mey wrote:
> Well, I don't know if I was on 'video' group but I did the addition.  I
> checked the file you sent me and it works. However, for the moment, I
> have 3 questions:
> 
> - If I don't activate the device in the right side of the patch, nor
> Blender nor VLC can get the image from /dev/video1 (VLC shows errors on
> console, Blender says nothing, but it makes black texture) Why is like
> that? Supposedly, being pix_record there and activated, I should get
> from where I want...

this could have a multitude of reasons.
i would suggest first checking what those errors are that VLC throws
(chances are they mean something).
then try using gstreamer(-0.10!) to display the video. something like:
  $ gst-launch0.10 v4l2src device=/dev/video1 ! ffmpegcolorspace !
xvimagesink

> - Look at the attached image: why the video is vertically inverted? I
> don't know about GEM, but I didn't find any object that do that.

it's the olde discrepancy between openGL image coordinates (starting in
the lower left corner) and most other pixel coordinates (starting in the
upper left corner), and a small bug in the old recordV4L2 implementation
of Gem (which should be fixed in recent git).
iirc putting a [pix_flip] before [pix_record] might fix the problem.

anyhow, this means that the v4l2loopback output is working.
so that leaves two more potential candidates for your problem:
- the v4l2loopback kernel module (there are some known issues with e.g.
gstreamer-1.0; which version are you using?)
- the consumer applications (blender/vlc): while working on the
v4l2loopback module i noticed that quite a number of v4l2 applications
make unjustified assumptions about the v4l2 device, which sometimes are
not satisfied by v4l2loopback. (like refusing to work when the card_name
does not match the device-name...)

> - How the patch should be if I want to send the GEM window to loopback?
> I mean, not only the color and vertical inverted video, but the whole
> window...

checkout [pix_snap] to fetch a framebuffer into pixes.


fgasm
IOhannes



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

Re: [PD] audio bit resolution in Pd

[Alexandre Torres Porres]

Yep, nice indeed, I guess I learned - in short and in layman's undetailed
terms - that audio output is ~24bits (a bit higher, but much higher for
smaller numbers).

Moreover, digital audio cards won't likely have more than 24 bit precision
for many years to come, so it's just way more than enough.

thanks


2015-04-23 6:43 GMT-03:00 Julian Brooks :

> Nice. Thanks Chuck, I learnt something.
>
> On 22 April 2015 at 23:45, Charles Z Henry  wrote:
>
>> On Wed, Apr 22, 2015 at 5:11 PM, Alexandre Torres Porres
>>  wrote:
>>
>> > So I start with this idea that the audio (values from -1 to 1) can't be
>> in
>> > full 32 bit float resolution, it's less. I don't see why that is
>> "wrong".
>> > And then, from it, my first question here was: "what is the audio
>> resolution
>> > then?". I'm still clueless here about this answer.
>> >
>> > Moreover, is it more or less than what 24 bit audio cards handle?
>>
>> Let me try:
>>
>> 32-bit floating point numbers have 24 bits of precision.  Always.  The
>> remaining 8 bits are just for the sign and exponent.  When the
>> amplitude of the signals decrease, you don't lose any precision in
>> floating-point.  The value of the least significant bit (LSB) gets
>> proportionally smaller.
>>
>> However, the output of a 24-bit soundcard always has a fixed
>> quantization.  The LSB is always the same size.  Smaller numbers have
>> less precision.
>>
>> The mismatch occurs when converting from the 32-bit floats to the
>> 24-bit fixed point numbers.  Now, the smaller numbers aren't as
>> precise anymore.  They get rounded to the nearest number in the 24-bit
>> fixed point system.
>>
>> So, yes, the resolution (of small numbers) in floating point (internal
>> to Pd) is finer than the resolution of those numbers when output
>> (driver/DAC).
>>
>> Also, the 24-bit fixed point format is for values between -1 and 1.
>> That means that numbers between 0 and 1 have just 23 bits.  In 32-bit
>> math, the numbers between 0.5 and 1 still have 24 bits of precision
>> (the sign is held elsewhere).  That means that Pd's internal
>> resolution is finer than the soundcard resolution for all numbers
>> between -1 and 1.
>>
>> Chuck
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] update Pd on Odroid-U3 running on Debian Jessy

[Alexandros Drymonitis]

I've installed Pd with apt-get on an Odroid-U3 running on Debian Jessy, but
I want to update it, as the Debian repositories now have Pd-0.46-2 and I
have Pd-0.46-0.
I did "apt-get update" and then "apt-get install puredata" but got these
errors:

dpkg: error processing package jackd2 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of gconf2:
 gconf2 depends on python:any.

dpkg: error processing package gconf2 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of
gstreamer0.10-gconf:armhf:
 gstreamer0.10-gconf:armhf depends on gconf2 (>= 2.28.1-2); however:
  Package gconf2 is not configured yet.

dpkg: error processing package gstreamer0.10-gconf:armhf (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of
gstreamer0.10-plugins-good:armhf:
 gstreamer0.10-plugins-good:armhf depends on gstreamer0.10-gconf; however:
  Package gstreamer0.10-gconf:armhf is not configured yet.

dpkg: error processing package gstreamer0.10-plugins-good:armhf
(--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of jackd:
 jackd depends on jackd2 | jackd1; however:
  Package jackd2 is not configured yet.
  Package jackd1 is not installed.

dpkg: error processing package jackd (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of python-numpy:
 python-numpy depends on python2.7:any.

dpkg: error processing package python-numpy (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of python-gtk2:
 python-gtk2 depends on python-numpy (>= 1:1.8.0); however:
  Package python-numpy is not configured yet.
 python-gtk2 depends on python-numpy-abi9; however:
  Package python-numpy-abi9 is not installed.
  Package python-numpy which provides python-numpy-abi9 is not configured
yet.

dpkg: error processing package python-gtk2 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of jack-mixer:
 jack-mixer depends on jackd; however:
  Package jackd is not configured yet.
 jack-mixer depends on python-gtk2; however:
  Package python-gtk2 is not configured yet.
 jack-mixer depends on gconf2 (>= 2.28.1-2); however:
  Package gconf2 is not configured yet.

dpkg: error processing package jack-mixer (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of jack-stdio:
 jack-stdio depends on jackd; however:
  Package jackd is not configured yet.

dpkg: error processing package jack-stdio (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of jack-tools:
 jack-tools depends on jackd; however:
  Package jackd is not configured yet.

dpkg: error processing package jack-tools (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libgksu2-0:
 libgksu2-0 depends on gconf2 (>= 2.28.1-2); however:
  Package gconf2 is not configured yet.

dpkg: error processing package libgksu2-0 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libgnome2-common:
 libgnome2-common depends on gconf2 (>= 2.28.1-2); however:
  Package gconf2 is not configured yet.

dpkg: error processing package libgnome2-common (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libgnomevfs2-common:
 libgnomevfs2-common depends on gconf2 (>= 2.28.1-2); however:
  Package gconf2 is not configured yet.

dpkg: error processing package libgnomevfs2-common (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libgnomevfs2-extra:armhf:
 libgnomevfs2-extra:armhf depends on libgnomevfs2-common (= 1:2.24.4-6);
however:
  Package libgnomevfs2-common is not configured yet.

dpkg: error processing package libgnomevfs2-extra:armhf (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of qjackctl:
 qjackctl depends on jackd; however:
  Package jackd is not configured yet.

dpkg: error processing package qjackctl (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 jackd2
 gconf2
 gstreamer0.10-gconf:armhf
 gstreamer0.10-plugins-good:armhf
 jackd
 python-numpy
 python-gtk2
 jack-mixer
 jack-stdio
 jack-tools
 libgksu2-0
 libgnome2-common
 libgnomevfs2-common
 libgnomevfs2-extra:armhf
 qjackctl
E: Sub-process /usr/bin/dpkg returned an error code (1)

I can understand there's a configuration problem with each one of these
packages, but I've no idea what I should do. Any help?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http:/

Re: [PD] audio bit resolution in Pd

[Julian Brooks]

Nice. Thanks Chuck, I learnt something.

On 22 April 2015 at 23:45, Charles Z Henry  wrote:

> On Wed, Apr 22, 2015 at 5:11 PM, Alexandre Torres Porres
>  wrote:
>
> > So I start with this idea that the audio (values from -1 to 1) can't be
> in
> > full 32 bit float resolution, it's less. I don't see why that is "wrong".
> > And then, from it, my first question here was: "what is the audio
> resolution
> > then?". I'm still clueless here about this answer.
> >
> > Moreover, is it more or less than what 24 bit audio cards handle?
>
> Let me try:
>
> 32-bit floating point numbers have 24 bits of precision.  Always.  The
> remaining 8 bits are just for the sign and exponent.  When the
> amplitude of the signals decrease, you don't lose any precision in
> floating-point.  The value of the least significant bit (LSB) gets
> proportionally smaller.
>
> However, the output of a 24-bit soundcard always has a fixed
> quantization.  The LSB is always the same size.  Smaller numbers have
> less precision.
>
> The mismatch occurs when converting from the 32-bit floats to the
> 24-bit fixed point numbers.  Now, the smaller numbers aren't as
> precise anymore.  They get rounded to the nearest number in the 24-bit
> fixed point system.
>
> So, yes, the resolution (of small numbers) in floating point (internal
> to Pd) is finer than the resolution of those numbers when output
> (driver/DAC).
>
> Also, the 24-bit fixed point format is for values between -1 and 1.
> That means that numbers between 0 and 1 have just 23 bits.  In 32-bit
> math, the numbers between 0.5 and 1 still have 24 bits of precision
> (the sign is held elsewhere).  That means that Pd's internal
> resolution is finer than the soundcard resolution for all numbers
> between -1 and 1.
>
> Chuck
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [Bulk] pd in a eurorack modular system

[Simon Wise]

On 21/04/15 07:42, Pagano, Patrick wrote:

I figured that would be what i would need to do
run pd with -nogui and arduino stuff that Hans wrote for the potentiometer 
control
a simple toggle on the faceplate that switches between maybe 5 patches that are 
unavailable in traditional analogia

1.) Phase Locking vocoder
2.) Granular synthesis
3.) FFT of some sort
4.) Sample and Hold, still need a patch that takes in a live osc~
5.) a waveform patch that loads a simple osc~/phasor for RIngMod/Am/FM etc...

The other issue is that the raspi that i have does NOT have a line in, only a 
line out for sound
i bought a little USB soundblaster card for that to see if i can get audio in 
to a ADC~


One of the cards using the digital audio interfaces is probably a better idea, 
to avoid all the very poor USB on the RPi.


I've used the Wolfson ones and they have proved very reliable (the main issue 
for me is that I can't use them directly from the GPU since I can't set them as 
the default output ... but via alsa from userspace they are great). They take a 
bit of setting up (a custom kernel which works fine with raspbian wheezy at 
least, plus a few scripts) but then are very flexible and control-able via alsa, 
including the ability to choose which audio clocks to use.


The version for the older models ...
http://www.adafruit.com/products/1761

There are also versions for the + models using the 40pin breakout.

There are also cards which have fewer in-out options but they are probably 
easier to use, I have not tried them 

https://www.hifiberry.com/


Simon


PS

I have some notes from a project here that may help setting the wolfsons up, a 
bit rambling but do have some useful info ...


https://www.dropbox.com/s/1scwpdufk41k4es/04.setupWolfsonAudio.txt


there is apparently a recently updated kernel for raspbian wheezy here ...

https://blog.georgmill.de/2015/02/18/update-for-wolfson-audio-card-on-raspberry-pi/

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