I have started writing my first jack application.
It's a simple combination of the qfileiconview example and jack.play (is that
a homage to ms?). Users of that OS might recognise the concept. It's a
FastWav2 clone.
It's very early days so this is untested but worked far so fine for me. I am
not
On Thursday 09 Jun 2005 23:16, fons adriaensen wrote:
>
> int access(int *v, int i)
> {
> return v[i];
> }
Of course, passing that pointer by value is horribly inefficient.
int access(int *const &v, int i)
{
return v[i];
}
Chris
On Thu, Jun 09, 2005 at 09:39:21PM +0300, Jussi Laako wrote:
> > int access(std::vector v, int i)
> > {
> > return v[i];
> > }
>
> At least you are making copy here, should be
>
> int access(std::vector &v, int i)
No such problem with
int access(int *v, int i)
{
return v[i];
}
:-) :-)
On Thu, 2005-06-09 at 09:47 -0400, Fred Gleason wrote:
[regarding writing full apps in asm]
> Today however, I think it'd be a foolish choice. Modern systems have orders
> of magnitude more processing power, and it'd be silly to devote 10x the time
> developing an assembly-based version of some
On Thu, Jun 09, 2005 at 08:23:57PM +0100, Chris Cannam wrote:
> On Thursday 09 Jun 2005 20:07, stefan kersten wrote:
> > On Thu, Jun 09, 2005 at 09:39:21PM +0300, Jussi Laako wrote:
> > > On Thu, 2005-06-09 at 18:14 +0200, stefan kersten wrote:
> > > > int access(std::vector v, int i)
> > >
> > > A
>a: a.cpp:5: A::A(const A&): Assertion `0' failed.
as an uncle of mine liked to quote "subtle as a flying mallet" :))
On Thursday 09 Jun 2005 20:07, stefan kersten wrote:
> On Thu, Jun 09, 2005 at 09:39:21PM +0300, Jussi Laako wrote:
> > On Thu, 2005-06-09 at 18:14 +0200, stefan kersten wrote:
> > > int access(std::vector v, int i)
> >
> > At least you are making copy here, should be
> > int access(std::vector &v,
On Thu, Jun 09, 2005 at 09:39:21PM +0300, Jussi Laako wrote:
> On Thu, 2005-06-09 at 18:14 +0200, stefan kersten wrote:
>
> > int access(std::vector v, int i)
> > {
> > return v[i];
> > }
>
> At least you are making copy here, should be
>
> int access(std::vector &v, int i)
actually not, s
>#include
>
>int access(int* v, int i)
>{=20
>return v[i];
>}=20
>
>int access(std::vector v, int i)
ahem. pass by reference vs. pass by value?
On Thu, 2005-06-09 at 18:14 +0200, stefan kersten wrote:
> int access(std::vector v, int i)
> {
> return v[i];
> }
At least you are making copy here, should be
int access(std::vector &v, int i)
--
Jussi Laako <[EMAIL PROTECTED]>
On Thu, Jun 09, 2005 at 11:41:00PM +0900, David Cournapeau wrote:
> The other problem "is [] as efficient for vector and plain
> c array ?"
possibly maybe:
#include
int access(int* v, int i)
{
return v[i];
}
int access(std::vector v, int i)
{
return v[i];
}
produces (g++ -fv
Martin Habets <[EMAIL PROTECTED]> writes:
> The RT limits solution implemented by some kernel folks puts a limit on
> the percentage of cpu time consumed by these processes, so other stuff
> should get some time to run as well.
To clarify: there *was* an experimental patch like this created six
m
On Wednesday 08 June 2005 09:12, Paul Davis wrote:
> SAWstudio is a pretty full-featured DAW that is, AFAIK, written almost
> entirely in x86 assembler. Its blazingly fast and yet dinosaur like at
> the same time, from what I hear.
I had a chance to meet Bob Lentini (SAW's developer) about ten yea
On Thu, 9 Jun 2005 23:41 , David Cournapeau <[EMAIL PROTECTED]> sent:
>On 6/9/05, stefan kersten [EMAIL PROTECTED]> wrote:
>> On Thu, Jun 09, 2005 at 10:31:35PM +0900, David Cournapeau wrote:
>> > _Z6vectorSt6vectorIiSaIiEE:
>> > .LFB539:
>> > .L2:
>> > .L7:
>> > pushl %ebp
>> > .LCFI0:
On 6/9/05, stefan kersten <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 09, 2005 at 10:31:35PM +0900, David Cournapeau wrote:
> > _Z6vectorSt6vectorIiSaIiEE:
> > .LFB539:
> > .L2:
> > .L7:
> > pushl %ebp
> > .LCFI0:
> > movl%esp, %ebp
> > .LCFI1:
> > popl%ebp
> > ret
>
On Thu, Jun 09, 2005 at 10:31:35PM +0900, David Cournapeau wrote:
> _Z6vectorSt6vectorIiSaIiEE:
> .LFB539:
> .L2:
> .L7:
> pushl %ebp
> .LCFI0:
> movl%esp, %ebp
> .LCFI1:
> popl%ebp
> ret
you've been bitten by the optimizer, this function does
nothing but return (
Howdy,
I am currently trying to get two HDSPM cards working with ALSA and JACK. I can
use each card individually from each other using -Dhw:0 or -Dhw:1. However I
need to get both cards to look like one card for a program that we are
developing in house. From what I have read I need either a .
> No, I am not. I cannot find the information on the C++ faq right now,
> but If m pretty sure that it is written in the book of Stroustrup.
>
Of course, once I press the send button, I find the relevant webpage:
http://www.research.att.com/~bs/3rd_tour2.pdf (page 9 of the pdf)
"3.7.2 Range Che
On 6/9/05, Erik de Castro Lopo <[EMAIL PROTECTED]> wrote:
> David Cournapeau wrote:
>
> > [EMAIL PROTECTED] wrote:
> >
> > >
> > >I was under the impression that there was bounds checking going on with
> > >vectors. Is this not the case?
> > >
> > >
> > >
> > Not necesserally: if you are usin
David Cournapeau wrote:
> [EMAIL PROTECTED] wrote:
>
> >
> >I was under the impression that there was bounds checking going on with
> >vectors. Is this not the case?
> >
> >
> >
> Not necesserally: if you are using operator (), yes, if you use operator
> [], no.
I think you are all guess
Hi Asbjørn!
On Wed, Jun 08, 2005 at 12:59:39PM +0200, Asbjørn Sæbø wrote:
> This is, I know, slightly off-topic for this group, as it does not deal
> with audio per se. It does, however, deal with the
> "real-time"/preemptible Linux kernel, for which I think most of the
> expertice is gathered
On Thu, 9 Jun 2005 08:29:21 +0200
[EMAIL PROTECTED] (Asbjørn Sæbø) wrote:
> On Wed, Jun 08, 2005 at 11:20:18AM -0500, Jack O'Quin wrote:
> > [EMAIL PROTECTED] (Asbjørn Sæbø) writes:
>
> [...]
> > > * If given a real-time kernel, what else is necessary to take advantage
> > > of its capabilitie
On Thursday 09 June 2005 12:46, Chris Cannam wrote:
> Jan Depner:
> > I was under the impression that there was bounds checking going on with
> > vectors. Is this not the case?
> Nope.
As far as I know the [] is not checked. but at() is...
Arnold
--
There is a theory which states that if ever
David Cournapeau wrote:
[EMAIL PROTECTED] wrote:
I was under the impression that there was bounds checking going on
with
vectors. Is this not the case?
Not necesserally: if you are using operator (), yes, if you use
operator [], no.
David
Sorry, you should read "vec.at(index) d
[EMAIL PROTECTED] wrote:
I was under the impression that there was bounds checking going on with
vectors. Is this not the case?
Not necesserally: if you are using operator (), yes, if you use operator
[], no.
David
Jan Depner:
> I was under the impression that there was bounds checking going on with
> vectors. Is this not the case?
Nope.
Chris
On Thu, 9 Jun 2005 10:05 , 'Chris Cannam' <[EMAIL PROTECTED]> sent:
>N Smethurst:
>> Since a vector is a wrapped C array (i.e. contigous), the [] operator
>> compiles to the C equivalent when optimisation is turned on.
>
>I was thinking of iterator operations, having vaguely recalled that the v
N Smethurst:
> Since a vector is a wrapped C array (i.e. contigous), the [] operator
> compiles to the C equivalent when optimisation is turned on.
I was thinking of iterator operations, having vaguely recalled that the vector
iterator in the gcc library had at some point changed from an actual
Jan Holst Jensen wrote:
> --- Clemens Ladisch <[EMAIL PROTECTED]> wrote:
> > > Are there any standard ioctl() calls in the
> >
> > No, but this would be a very good idea for testing
> > purposes. I'll add a hwdep device for this.
>
> Great. Looking forward to that. But until then, my
> best shot i
Chris Cannam a écrit :
Yes, indeed, but a couple of times here I've seen observations that a
vector would compile to an array if optimisation was on, etc. Since
we're mostly using gcc-3.3+ now, I wanted to ask if anyone is sure
whether that's really true.
Since a vector is a wrapped C arra
30 matches
Mail list logo
