Discussion:
Contribution to STARTER tickets?
(too old to reply)
William Spinelli
2015-08-19 21:20:50 UTC
Permalink
Hi,

I’ve been using PortAudio for some simple personal programs. It’s a very
cool project and I would like to learn more about it and also to help out
if I can...

I have seen that there are some STARTER tickets listed for new
contributors, but they are quite old.
Are they still valid? If yes, I can start with a couple of easy tasks like
ticket #201 and #69.

If this could be helpful, please let me know how to proceed.

Thanks
william
Riot
2015-08-19 21:32:35 UTC
Permalink
The way it works here is you just send your patch to the mailing list for
review (the site's issue tracker claims to allow this but doesn't) and then
you have a 30% chance of it being accepted in about two months and a 60%
chance of it being ignored completely and adout a 10% chance of it never
being received because the mailing list is being migrated again without
notice for the third time this year. Just the same as all other dinosauric
svn-based cathedral projects really
Post by William Spinelli
Hi,
I’ve been using PortAudio for some simple personal programs. It’s a very
cool project and I would like to learn more about it and also to help out
if I can...
I have seen that there are some STARTER tickets listed for new
contributors, but they are quite old.
Are they still valid? If yes, I can start with a couple of easy tasks
like ticket #201 and #69.
If this could be helpful, please let me know how to proceed.
Thanks
william
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Ross Bencina
2015-08-19 23:59:29 UTC
Permalink
Hello Riot,

Your criticisms are partially accurate. However, being snarky in the
direction of a potential contributor is not helpful.

If you feel that you patches are being ignored, please repost your
requests to the list. Reviewing and merging patches generally falls to
the individual module maintainers.
Post by Riot
The way it works here is you just send your patch to the mailing list
for review (the site's issue tracker claims to allow this but doesn't)
That issue has been "fixed" (although not to my satisfaction). It is
possible to post a ticket without being added as a core developer on
Assembla:

https://www.assembla.com/spaces/portaudio/support/tickets

"New support request" button, top right.
Post by Riot
and then you have a 30% chance of it being accepted in about two months
and a 60% chance of it being ignored completely
As far as I can see you've posted the following patches. Please let me
know if I've missed any.

1. C++ const operator patch (merged)
2. CMake patch (not sure whether merged)

If it hasn't already been merged, the CMake patch needs to be merged by
someone who can review and test it. That would be Robert Bielik.

When changes are specific to a particular host API or other component
with a specific maintainer, it is possible that the maintainer is
unavailable and/or didn't see your request. In a few cases there is no
maintainer (e.g. C++ bindings) or the maintainer hasn't been seen lately
(e.g. WASAPI).

I understand that this is frustrating, but please understand that
reviewing and testing patches is necessary and important. We are spread
across multiple operating systems, so not everyone is equipped or
competent to test every contribution (in general I'd say there's only
one or two people who could review any particular contribution).
Post by Riot
and adout a 10% chance
of it never being received because the mailing list is being migrated
again without notice for the third time this year.
The mailing list was migrated for the first and only time last month. At
least one message did not get through. I believe that the mailing list
is working correctly now. Please repost if something got dropped.
Post by Riot
Just the same as all
other dinosauric svn-based cathedral projects really
Cheers,

Ross.
Post by Riot
The way it works here is you just send your patch to the mailing list
for review (the site's issue tracker claims to allow this but doesn't)
and then you have a 30% chance of it being accepted in about two months
and a 60% chance of it being ignored completely and adout a 10% chance
of it never being received because the mailing list is being migrated
again without notice for the third time this year. Just the same as all
other dinosauric svn-based cathedral projects really
j***@gmail.com
2015-08-20 00:48:32 UTC
Permalink
Hi Ross :) long, long, long time listener, rare caller. Fan of much of
the work that you and Phil have done in the past.

So, I too feel I owe some sort of debt to you and the portaudio project,
considering I've been using it in various forms, for various projects, for
at least 7 years, probably longer.

I'd like to help out too, but don't quite know where to start, and, because
time is such a fleeting resource, I'd like to start off helping with
contributions that benefit the most people, probably also which overlap
with skills I have which others might not.

If its not worth your time to point out, that's fine-- I'll probably go
through the bug list at some point and look for myself, but, here are a
rough list of skills and experience I have, and if you can direct me
towards something useful you think I could contribute, I'd love that:

I was in my past a heavy perl user (and still am), and, I think around 2005
(?) I got about 70% of the way towards what I consider to be the correct
way to bridge the gap and have high performance callback oriented perl Apis
for PA. Now, I know that the language isn't as popular as it once was, but
if the community felt enough to convince me that it would be useful, I
could certainly do that.

Same thing for MATLAB. High quality (in terms of performance) bindings
for PA, allowing one to develop things using PA in that language.

I think I'm decently strong at systems engineering, low level optimization
and performance, those sorts of things, so if there was some high impact
problem or are of the code base I could help out on, that might be fun.

Linux is my primary platform, c and c++ are what I write most of the time.

I do have pretty strong release engineering experience, specifically with
svn. Also have experience with windows, though I won't bother keeping up
with anything newer than windows 7, so maybe not that.

I could also see myself doing a solid port to iOS, though that would be so
'un sexy' to me that I'd almost want someone else to sponsor it ;)

So yeah, to recap, and in short: what are the biggest pain points right
now? Anything I can help?

Joshua

Also, "riot", I don't know you, but come on, don't be so lame like that.
When new people want to help out, that's not an invitation for "stop
energy". You might be right about all your criticisms, but throwing stop
energy at a new potential contributor doesn't help, and you should know
better :p ;)
Post by Ross Bencina
Hello Riot,
Your criticisms are partially accurate. However, being snarky in the
direction of a potential contributor is not helpful.
If you feel that you patches are being ignored, please repost your
requests to the list. Reviewing and merging patches generally falls to the
individual module maintainers.
Post by Riot
The way it works here is you just send your patch to the mailing list
for review (the site's issue tracker claims to allow this but doesn't)
That issue has been "fixed" (although not to my satisfaction). It is
possible to post a ticket without being added as a core developer on
https://www.assembla.com/spaces/portaudio/support/tickets
"New support request" button, top right.
Post by Riot
and then you have a 30% chance of it being accepted in about two months
and a 60% chance of it being ignored completely
As far as I can see you've posted the following patches. Please let me
know if I've missed any.
1. C++ const operator patch (merged)
2. CMake patch (not sure whether merged)
If it hasn't already been merged, the CMake patch needs to be merged by
someone who can review and test it. That would be Robert Bielik.
When changes are specific to a particular host API or other component with
a specific maintainer, it is possible that the maintainer is unavailable
and/or didn't see your request. In a few cases there is no maintainer (e.g.
C++ bindings) or the maintainer hasn't been seen lately (e.g. WASAPI).
I understand that this is frustrating, but please understand that
reviewing and testing patches is necessary and important. We are spread
across multiple operating systems, so not everyone is equipped or competent
to test every contribution (in general I'd say there's only one or two
people who could review any particular contribution).
Post by Riot
and adout a 10% chance
of it never being received because the mailing list is being migrated
again without notice for the third time this year.
The mailing list was migrated for the first and only time last month. At
least one message did not get through. I believe that the mailing list is
working correctly now. Please repost if something got dropped.
Post by Riot
Just the same as all
other dinosauric svn-based cathedral projects really
Cheers,
Ross.
Post by Riot
The way it works here is you just send your patch to the mailing list
for review (the site's issue tracker claims to allow this but doesn't)
and then you have a 30% chance of it being accepted in about two months
and a 60% chance of it being ignored completely and adout a 10% chance
of it never being received because the mailing list is being migrated
again without notice for the third time this year. Just the same as all
other dinosauric svn-based cathedral projects really
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Ross Bencina
2015-08-22 10:29:39 UTC
Permalink
Hi Joshua,
Post by j***@gmail.com
I'd like to help out too, but don't quite know where to start, and,
because time is such a fleeting resource, I'd like to start off helping
with contributions that benefit the most people, probably also which
overlap with skills I have which others might not.
Thanks for the offer of help. It is welcome.

I think it is best to systematically work through closing the scheduled
milestones as this lowers technical debt. Closing out any one ticket is
a step in that direction. Here's the full list, ordered by milestone:

https://www.assembla.com/spaces/arhHGeUuSr4k70eJe4gwI3/tickets?tickets_report_id=1
Post by j***@gmail.com
If its not worth your time to point out, that's fine-- I'll probably go
through the bug list at some point and look for myself,
There is a list of "starter" tickets for first-time contributors. There
is an introduction and a link to the list here:

https://www.assembla.com/wiki/show/portaudio/TasksForNewContributors
Post by j***@gmail.com
but, here are a
rough list of skills and experience I have, and if you can direct me
I was in my past a heavy perl user (and still am), and, I think around
2005 (?) I got about 70% of the way towards what I consider to be the
correct way to bridge the gap and have high performance callback
oriented perl Apis for PA. Now, I know that the language isn't as
popular as it once was, but if the community felt enough to convince me
that it would be useful, I could certainly do that.
Same thing for MATLAB. High quality (in terms of performance) bindings
for PA, allowing one to develop things using PA in that language.
I don't consider bindings to be a core part of the PA project. Probably
we should split out the existing bindings into separate projects.

At one stage I had aspirations to exert control over the bindings so
that they were kept consistent with the PA C API. I no longer believe
that is achievable or necessarily desirable.

So by all means develop a binding, and of course we'll support you here.
But contributing to the core would be preferable to me. It would
certainly help the most people.
Post by j***@gmail.com
I think I'm decently strong at systems engineering, low level
optimization and performance, those sorts of things, so if there was
some high impact problem or are of the code base I could help out on,
that might be fun.
As far as I know there aren't any outstanding perf issues. There are
some missing perf-critical data converters that could use some love:

https://www.assembla.com/spaces/portaudio/tickets/35

Alternatively, I have a more ambitious project to replace the hand-coded
pa_converters.c with a script that generates them (this will allow
adding byte swapping converters as well). I would be happy to
collaborate on that.
Post by j***@gmail.com
Linux is my primary platform, c and c++ are what I write most of the time.
Alan might have some Linux-specific tasks in mind. You could search the
tickets for Linux.
Post by j***@gmail.com
I do have pretty strong release engineering experience, specifically
with svn.
That said, it doesn't have to be code, it could be build engineering
(documenting and realising our policy for ./configure, cmake, project
files etc. maybe removing scons(?)), documentation, setting up CI
infrastructure, etc. e.g. It would be great if Phil's pa_qa tests were
run regularly.

If we stick to the plan and decide to reorganise the svn repo to use
standard structure you could help with that.
Post by j***@gmail.com
Also have experience with windows, though I won't bother
keeping up with anything newer than windows 7, so maybe not that.
I'm still on Windows 7 myself.

If you were interested in a more extended project, there is the hot-plug
branch, which has been developed to a certain level but needs someone
with commitment to guiding it through (1) completion on a single
OS/hostAPI, (2) merging stubs for all other host APIs. Right now the PoC
is on Windows, which is why I mention it here.
Post by j***@gmail.com
I could also see myself doing a solid port to iOS, though that would be
so 'un sexy' to me that I'd almost want someone else to sponsor it ;)
So yeah, to recap, and in short: what are the biggest pain points right
now? Anything I can help?
Here are a few other options off the top of my head:

- Pick a starter ticket and fix it

- Go looking at some of these repos and github and mine potential patches.

- Help me work through a ticket that maybe you can't do by yourself (and
probably I won't make time to do without some concrete social commitment
with another human being).


A lot of the ticketed development falls in to one of two categories:

(1) Stuff that is easy enough that I have left it for other people to
pick up.

(2) Stuff that is difficult enough that it needs either (a) full time
attention, or (b) concerted collaboration between multiple devs with a
commitment to complete the job.

Obviously my time is limited but I'm happy to work with someone on any
ticket if they can provide the impetus to see it through to completion.

Hope that helps,

Ross.
Post by j***@gmail.com
Joshua
Also, "riot", I don't know you, but come on, don't be so lame like
that. When new people want to help out, that's not an invitation for
"stop energy". You might be right about all your criticisms, but
throwing stop energy at a new potential contributor doesn't help, and
you should know better :p ;)
Hello Riot,
Your criticisms are partially accurate. However, being snarky in the
direction of a potential contributor is not helpful.
If you feel that you patches are being ignored, please repost your
requests to the list. Reviewing and merging patches generally falls
to the individual module maintainers.
Post by Riot
The way it works here is you just send your patch to the mailing list
for review (the site's issue tracker claims to allow this but
doesn't)
That issue has been "fixed" (although not to my satisfaction). It is
possible to post a ticket without being added as a core developer on
https://www.assembla.com/spaces/portaudio/support/tickets
"New support request" button, top right.
Post by Riot
and then you have a 30% chance of it being accepted in about two
months
Post by Riot
and a 60% chance of it being ignored completely
As far as I can see you've posted the following patches. Please let
me know if I've missed any.
1. C++ const operator patch (merged)
2. CMake patch (not sure whether merged)
If it hasn't already been merged, the CMake patch needs to be merged
by someone who can review and test it. That would be Robert Bielik.
When changes are specific to a particular host API or other
component with a specific maintainer, it is possible that the
maintainer is unavailable and/or didn't see your request. In a few
cases there is no maintainer (e.g. C++ bindings) or the maintainer
hasn't been seen lately (e.g. WASAPI).
I understand that this is frustrating, but please understand that
reviewing and testing patches is necessary and important. We are
spread across multiple operating systems, so not everyone is
equipped or competent to test every contribution (in general I'd say
there's only one or two people who could review any particular
contribution).
Post by Riot
and adout a 10% chance
of it never being received because the mailing list is being migrated
again without notice for the third time this year.
The mailing list was migrated for the first and only time last
month. At least one message did not get through. I believe that the
mailing list is working correctly now. Please repost if something
got dropped.
Post by Riot
Just the same as all
other dinosauric svn-based cathedral projects really
Cheers,
Ross.
The way it works here is you just send your patch to the mailing list
for review (the site's issue tracker claims to allow this but doesn't)
and then you have a 30% chance of it being accepted in about two months
and a 60% chance of it being ignored completely and adout a 10% chance
of it never being received because the mailing list is being migrated
again without notice for the third time this year. Just the same as all
other dinosauric svn-based cathedral projects really
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Riot
2015-08-20 03:25:52 UTC
Permalink
Sorry folks, please don't take it the wrong way - my sarcastic comments
were only intended to be light-hearted tongue in cheek really. In all
seriousness I very much appreciate the work everyone involved with the
project does, and I wouldn't even consider switching away from PortAudio
myself.

It's true that I would have submitted a few more patches by now if I hadn't
been put off somewhat by the extremely grating process, but I don't in any
way blame you Ross or anyone else involved for that personally.

The real brunt of my criticism is about the continuing use of SVN with a
few "elite" contributors who have to manually merge everything, and I think
the other issues here all center around that. I've spoken before about how
I believe the project would grow, and become vastly more accessible, if its
primary repository was on Github. It would make the process of submitting
patches far less painful using pull requests, and it would no doubt make
the process of review and acceptance / discussion far more streamlined from
your point of view, too, Ross. And it would make discussions such as this
entirely unnecessary, exactly because there would be a very clear and
intuitive way for newcomers to contribute to the project, without having to
join a mailing list and jump through all these beaurocratic hoops. That
was the target of my "dinosauric cathedral" comment, and again, it wasn't
at all intended to be personal - I only want to see the project grow and
become more accessible to a greater number of quality contributors.

Regards,
Riot
Post by Ross Bencina
Hello Riot,
Your criticisms are partially accurate. However, being snarky in the
direction of a potential contributor is not helpful.
If you feel that you patches are being ignored, please repost your
requests to the list. Reviewing and merging patches generally falls to the
individual module maintainers.
Post by Riot
The way it works here is you just send your patch to the mailing list
for review (the site's issue tracker claims to allow this but doesn't)
That issue has been "fixed" (although not to my satisfaction). It is
possible to post a ticket without being added as a core developer on
https://www.assembla.com/spaces/portaudio/support/tickets
"New support request" button, top right.
Post by Riot
and then you have a 30% chance of it being accepted in about two months
and a 60% chance of it being ignored completely
As far as I can see you've posted the following patches. Please let me
know if I've missed any.
1. C++ const operator patch (merged)
2. CMake patch (not sure whether merged)
If it hasn't already been merged, the CMake patch needs to be merged by
someone who can review and test it. That would be Robert Bielik.
When changes are specific to a particular host API or other component with
a specific maintainer, it is possible that the maintainer is unavailable
and/or didn't see your request. In a few cases there is no maintainer (e.g.
C++ bindings) or the maintainer hasn't been seen lately (e.g. WASAPI).
I understand that this is frustrating, but please understand that
reviewing and testing patches is necessary and important. We are spread
across multiple operating systems, so not everyone is equipped or competent
to test every contribution (in general I'd say there's only one or two
people who could review any particular contribution).
Post by Riot
and adout a 10% chance
of it never being received because the mailing list is being migrated
again without notice for the third time this year.
The mailing list was migrated for the first and only time last month. At
least one message did not get through. I believe that the mailing list is
working correctly now. Please repost if something got dropped.
Post by Riot
Just the same as all
other dinosauric svn-based cathedral projects really
Cheers,
Ross.
Post by Riot
The way it works here is you just send your patch to the mailing list
for review (the site's issue tracker claims to allow this but doesn't)
and then you have a 30% chance of it being accepted in about two months
and a 60% chance of it being ignored completely and adout a 10% chance
of it never being received because the mailing list is being migrated
again without notice for the third time this year. Just the same as all
other dinosauric svn-based cathedral projects really
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Phil Burk
2015-08-20 15:20:45 UTC
Permalink
@William, thanks for offering to contribute back to PortAudio. I think
#201, the latency printer, would be a great start.

@Joshua, the MATLAB and Perl wrappers sound useful. But I wonder if they
might best be done as GitHub projects. Then you would have control over the
repository. Also I really like GitHub. Fixing C bugs in the main repository
is always helpful. If you start working on one then assign it to yourself
to avoid duplication.

@Riot, your comments are mostly valid. But please don't discourage new
volunteers. Regarding GitHub, I agree. But let's move that to a different
topic and keep this one on William and Joshua's volunteer efforts.

Thanks
Phil Burk
Post by Riot
Sorry folks, please don't take it the wrong way - my sarcastic comments
were only intended to be light-hearted tongue in cheek really. In all
seriousness I very much appreciate the work everyone involved with the
project does, and I wouldn't even consider switching away from PortAudio
myself.
It's true that I would have submitted a few more patches by now if I
hadn't been put off somewhat by the extremely grating process, but I don't
in any way blame you Ross or anyone else involved for that personally.
The real brunt of my criticism is about the continuing use of SVN with a
few "elite" contributors who have to manually merge everything, and I think
the other issues here all center around that. I've spoken before about how
I believe the project would grow, and become vastly more accessible, if its
primary repository was on Github. It would make the process of submitting
patches far less painful using pull requests, and it would no doubt make
the process of review and acceptance / discussion far more streamlined from
your point of view, too, Ross. And it would make discussions such as this
entirely unnecessary, exactly because there would be a very clear and
intuitive way for newcomers to contribute to the project, without having to
join a mailing list and jump through all these beaurocratic hoops. That
was the target of my "dinosauric cathedral" comment, and again, it wasn't
at all intended to be personal - I only want to see the project grow and
become more accessible to a greater number of quality contributors.
Regards,
Riot
Post by Ross Bencina
Hello Riot,
Your criticisms are partially accurate. However, being snarky in the
direction of a potential contributor is not helpful.
If you feel that you patches are being ignored, please repost your
requests to the list. Reviewing and merging patches generally falls to the
individual module maintainers.
Post by Riot
The way it works here is you just send your patch to the mailing list
for review (the site's issue tracker claims to allow this but doesn't)
That issue has been "fixed" (although not to my satisfaction). It is
possible to post a ticket without being added as a core developer on
https://www.assembla.com/spaces/portaudio/support/tickets
"New support request" button, top right.
Post by Riot
and then you have a 30% chance of it being accepted in about two months
and a 60% chance of it being ignored completely
As far as I can see you've posted the following patches. Please let me
know if I've missed any.
1. C++ const operator patch (merged)
2. CMake patch (not sure whether merged)
If it hasn't already been merged, the CMake patch needs to be merged by
someone who can review and test it. That would be Robert Bielik.
When changes are specific to a particular host API or other component
with a specific maintainer, it is possible that the maintainer is
unavailable and/or didn't see your request. In a few cases there is no
maintainer (e.g. C++ bindings) or the maintainer hasn't been seen lately
(e.g. WASAPI).
I understand that this is frustrating, but please understand that
reviewing and testing patches is necessary and important. We are spread
across multiple operating systems, so not everyone is equipped or competent
to test every contribution (in general I'd say there's only one or two
people who could review any particular contribution).
Post by Riot
and adout a 10% chance
of it never being received because the mailing list is being migrated
again without notice for the third time this year.
The mailing list was migrated for the first and only time last month. At
least one message did not get through. I believe that the mailing list is
working correctly now. Please repost if something got dropped.
Post by Riot
Just the same as all
other dinosauric svn-based cathedral projects really
Cheers,
Ross.
Post by Riot
The way it works here is you just send your patch to the mailing list
for review (the site's issue tracker claims to allow this but doesn't)
and then you have a 30% chance of it being accepted in about two months
and a 60% chance of it being ignored completely and adout a 10% chance
of it never being received because the mailing list is being migrated
again without notice for the third time this year. Just the same as all
other dinosauric svn-based cathedral projects really
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
j***@gmail.com
2015-08-20 19:33:17 UTC
Permalink
Post by Phil Burk
@Joshua, the MATLAB and Perl wrappers sound useful. But I wonder if they
might best be done as GitHub projects. Then you would have control over the
repository. Also I really like GitHub. Fixing C bugs in the main repository
is always helpful. If you start working on one then assign it to yourself
to avoid duplication.
Okay cool. Honestly, I'm much more comfortable with svn than git and
github but I may be a minority. :)

My comments about the Perl and MATLAB native interfaces were mostly that
this would be a relatively easy thing for me to build (and when I say
native interface, I mean it. none of this blocking API only stuff, but
first class low latency callback based interfaces, probably using shared
memory tricks and all sorts of other fun hackery) compared to anyone else,
but still a decent amount of work. So I'm not THAT inclined to do it
unless you, or the community, saw real value. (though I still might do it,
just at a lower priority)

My impression is that these days, kids don't use Perl as much, and I've
always been an outlier with my predilection for MATLAB.

I will look on the BTS for a list of "C bugs in the main repository", and
go from there? Thanks!

(also, i've been doing some "more mathy" research about new more
computationally efficient structures for sample rate conversion, offering a
2 or 4 fold decrease in the number of multiplies while not sacrificing
accuracy, using various new kinds of filterbank designs based on stable
EMQF IIR thingies, but that's still a ways off from being ready for
widespread adoption)

Joshua
William Spinelli
2015-08-20 19:53:32 UTC
Permalink
Hi Ross,

I have created an account on Assembla (wspinelli). When you will give me
editing rights I will complete ticket #69.

Regarding ticket #201, my plan is to create a simple test that will fail if
the input/output latency is <= 0.
For sure I will not consider output latency for input only device and the
opposite (or I will make sure that it is -1)
Then I will try to work through ticket #202 (at least for the API that I
can enabled and test).

Ok... Let's see what will come out =)

Thanks
william
Post by j***@gmail.com
Post by Phil Burk
@Joshua, the MATLAB and Perl wrappers sound useful. But I wonder if they
might best be done as GitHub projects. Then you would have control over the
repository. Also I really like GitHub. Fixing C bugs in the main repository
is always helpful. If you start working on one then assign it to yourself
to avoid duplication.
Okay cool. Honestly, I'm much more comfortable with svn than git and
github but I may be a minority. :)
My comments about the Perl and MATLAB native interfaces were mostly that
this would be a relatively easy thing for me to build (and when I say
native interface, I mean it. none of this blocking API only stuff, but
first class low latency callback based interfaces, probably using shared
memory tricks and all sorts of other fun hackery) compared to anyone else,
but still a decent amount of work. So I'm not THAT inclined to do it
unless you, or the community, saw real value. (though I still might do it,
just at a lower priority)
My impression is that these days, kids don't use Perl as much, and I've
always been an outlier with my predilection for MATLAB.
I will look on the BTS for a list of "C bugs in the main repository", and
go from there? Thanks!
(also, i've been doing some "more mathy" research about new more
computationally efficient structures for sample rate conversion, offering a
2 or 4 fold decrease in the number of multiplies while not sacrificing
accuracy, using various new kinds of filterbank designs based on stable
EMQF IIR thingies, but that's still a ways off from being ready for
widespread adoption)
Joshua
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Ross Bencina
2015-08-22 10:30:50 UTC
Permalink
Hi William,
Post by William Spinelli
I have created an account on Assembla (wspinelli). When you will give
me editing rights I will complete ticket #69.
You should now have editing rights.
Post by William Spinelli
Regarding ticket #201, my plan is to create a simple test that will fail
if the input/output latency is <= 0.
For sure I will not consider output latency for input only device and
the opposite (or I will make sure that it is -1)
Then I will try to work through ticket #202 (at least for the API that I
can enabled and test).
Thanks. If the test prints a table of output we can get different people
to run it on various platforms and collate the results on the wiki.

The intent of #69, #201 is to provide a diagnostic tool, and to perform
a one-time manual review across all platforms. The diagnostic provides a
starting point for implementers to fix bugs or work out a solution on a
new platform.

It may well be that the pa_qa tests already do a default-latency > 0
check. If not, that should also be done. @Phil: do you know whether the
qa code already does that?

Thank you,

Ross.
Post by William Spinelli
Hi Ross,
I have created an account on Assembla (wspinelli). When you will give
me editing rights I will complete ticket #69.
Regarding ticket #201, my plan is to create a simple test that will fail
if the input/output latency is <= 0.
For sure I will not consider output latency for input only device and
the opposite (or I will make sure that it is -1)
Then I will try to work through ticket #202 (at least for the API that I
can enabled and test).
Ok... Let's see what will come out =)
Thanks
william
Ross Bencina
2015-08-19 23:54:50 UTC
Permalink
Hello William,

Thank you for offering to help out.
I’ve been using PortAudio for some simple personal programs. It’s a
very cool project and I would like to learn more about it and also to
help out if I can...
I have seen that there are some STARTER tickets listed for new
contributors, but they are quite old.
Are they still valid?
In general yes they are. It would be great if you could help out.
If yes, I can start with a couple of easy tasks
like ticket #201 and #69.
If this could be helpful, please let me know how to proceed.
Yes it would be helpful.

Please create an account at Assembla and I'll give you access to editing
the wiki, for #69.

Let me know if you have any specific questions about implementing #201.

Regarding committing: the way we work with new contributors is that one
of the main developers reviews contributions and checks them in. In the
case of #201 it's probably easiest to email me drafts of the file (to
***@audiomulch.com) and we can discuss revisions. If you post the code
somewhere else I can look at it there too.

Thank you!

Ross.
Hi,
I’ve been using PortAudio for some simple personal programs. It’s a
very cool project and I would like to learn more about it and also to
help out if I can...
I have seen that there are some STARTER tickets listed for new
contributors, but they are quite old.
Are they still valid? If yes, I can start with a couple of easy tasks
like ticket #201 and #69.
If this could be helpful, please let me know how to proceed.
Thanks
william
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Loading...