Hi, I have just released the initial beta of a C# project called
'aumplib'. aumplib is a C# namespace which is made up of a set of
classes that interface several prominent open source audio conversion
projects via DLL and P/Invoke: LAME (MP3 encoding), libsndfile (non-MP3
audio conversion), and libmad (MP3 decoding; through madlldlib).
Essentially, aumplib provides an OO wrapper to these libraries.
I am interested in any comments anyone would like to make on the code.
I've been programming C# for less than a year (programming in other
languages longer), and would like to ensure that I haven't made some
faux pas in regard to the use of C#. Please be constructive if you want
to comment.
You can download the source at: http://www.arbingersys.com/dnlds/aumplib-1.0b1.zip
(There's too many source files to try and paste into this message.) If
you wish to leave your comments or questions in my development forum you
can: http://www.arbingersys.com/forums/viewforum.php?f=3
A short outline of how the namespace is arranged is below.
namespace aumplib {
- class aumpifc
[Primary interface to other classes]
- class lame_wrap
[Interfaces with LAME DLL, lame_enc.dll, for MP3 encoding]
- class lame_write
[Uses lame_wrap and overrides BinaryWriter for easier usage in C#]
- class libsndf_wrap
[Interfaces with libsndfile.dll to convert between many non-MP3 audio
formats]
- class madlldlib_wrap
[Interfaces to madlldlib, a DLL for decoding MP3]
- class madnpsrv_wrap
[Uses named pipes to communicate to madlldlib for MP3 decoding]
}
Thanks, James 14  3026 
I didn't see anything that popped out, but as some constructive criticism,
your "interface" to your developer users is sort of confusing and
intimidating.
On the one hand, you don't want to have this Fisher-Price "My First
Programming Object", but on the other hand, there is nothing wrong with
making things nice and simple. A developer has other things to do, your
object should HELP him by being easy to use and intuitive.
As a general rule (at least nowadays and in .NET) - method arguments should
have regular names, and no prefixes. In other words:
lame_write(Stream ostrm, string ifilnm)
should be prettied up to be (ALWAYS use verb-noun, like GetUser(),
AddCompany(), DeleteStream(), etc):
WriteLame(Stream OutputStream, string FullPathAndFilename)
Point is, when you have all your functionality, you should spend some time
to make the developer interface as clean and simple as possible. They have
better things to do than to try to figure out what you were thinking or
trying to make sense of these eye-crossing bunch of letters - like "ostrm"
and "ifilnm"!!
Just my $.02 - no offense!!
<gi***@arbingersysBADSPAMBOT.com> wrote in message
news:e$**************@TK2MSFTNGP09.phx.gbl... Hi, I have just released the initial beta of a C# project called
'aumplib'. aumplib is a C# namespace which is made up of a set of classes
that interface several prominent open source audio conversion projects via
DLL and P/Invoke: LAME (MP3 encoding), libsndfile (non-MP3 audio
conversion), and libmad (MP3 decoding; through madlldlib). Essentially,
aumplib provides an OO wrapper to these libraries.
I am interested in any comments anyone would like to make on the code.
I've been programming C# for less than a year (programming in other
languages longer), and would like to ensure that I haven't made some faux
pas in regard to the use of C#. Please be constructive if you want to
comment.
You can download the source at:
http://www.arbingersys.com/dnlds/aumplib-1.0b1.zip
(There's too many source files to try and paste into this message.) If you
wish to leave your comments or questions in my development forum you can:
http://www.arbingersys.com/forums/viewforum.php?f=3
A short outline of how the namespace is arranged is below.
namespace aumplib {
- class aumpifc
[Primary interface to other classes]
- class lame_wrap
[Interfaces with LAME DLL, lame_enc.dll, for MP3 encoding]
- class lame_write
[Uses lame_wrap and overrides BinaryWriter for easier usage in C#]
- class libsndf_wrap
[Interfaces with libsndfile.dll to convert between many non-MP3 audio
formats]
- class madlldlib_wrap
[Interfaces to madlldlib, a DLL for decoding MP3]
- class madnpsrv_wrap
[Uses named pipes to communicate to madlldlib for MP3 decoding]
}
Thanks, James
I agree with you, except i disagree with using PascalCasing in parameter
names:
WriteLame(Stream OutputStream, string FullPathAndFilename)
I would rather use camelCasing:
WriteLame(Stream outputStream, string filename)
Well, that is my opinion anyway.
--
Regards,
Dennis JD Myrén
Oslo Kodebureau
"Drebin" <th*******@hotmail.com> wrote in message
news:Zq******************@newssvr19.news.prodigy.c om... I didn't see anything that popped out, but as some constructive criticism,
your "interface" to your developer users is sort of confusing and
intimidating.
On the one hand, you don't want to have this Fisher-Price "My First
Programming Object", but on the other hand, there is nothing wrong with
making things nice and simple. A developer has other things to do, your
object should HELP him by being easy to use and intuitive.
As a general rule (at least nowadays and in .NET) - method arguments
should have regular names, and no prefixes. In other words:
lame_write(Stream ostrm, string ifilnm)
should be prettied up to be (ALWAYS use verb-noun, like GetUser(),
AddCompany(), DeleteStream(), etc):
WriteLame(Stream OutputStream, string FullPathAndFilename)
Point is, when you have all your functionality, you should spend some time
to make the developer interface as clean and simple as possible. They have
better things to do than to try to figure out what you were thinking or
trying to make sense of these eye-crossing bunch of letters - like "ostrm"
and "ifilnm"!!
Just my $.02 - no offense!!
<gi***@arbingersysBADSPAMBOT.com> wrote in message
news:e$**************@TK2MSFTNGP09.phx.gbl... Hi, I have just released the initial beta of a C# project called
'aumplib'. aumplib is a C# namespace which is made up of a set of classes
that interface several prominent open source audio conversion projects
via DLL and P/Invoke: LAME (MP3 encoding), libsndfile (non-MP3 audio
conversion), and libmad (MP3 decoding; through madlldlib). Essentially,
aumplib provides an OO wrapper to these libraries.
I am interested in any comments anyone would like to make on the code.
I've been programming C# for less than a year (programming in other
languages longer), and would like to ensure that I haven't made some faux
pas in regard to the use of C#. Please be constructive if you want to
comment.
You can download the source at:
http://www.arbingersys.com/dnlds/aumplib-1.0b1.zip
(There's too many source files to try and paste into this message.) If
you wish to leave your comments or questions in my development forum you
can:
http://www.arbingersys.com/forums/viewforum.php?f=3
A short outline of how the namespace is arranged is below.
namespace aumplib {
- class aumpifc
[Primary interface to other classes]
- class lame_wrap
[Interfaces with LAME DLL, lame_enc.dll, for MP3 encoding]
- class lame_write
[Uses lame_wrap and overrides BinaryWriter for easier usage in C#]
- class libsndf_wrap
[Interfaces with libsndfile.dll to convert between many non-MP3 audio
formats]
- class madlldlib_wrap
[Interfaces to madlldlib, a DLL for decoding MP3]
- class madnpsrv_wrap
[Uses named pipes to communicate to madlldlib for MP3 decoding]
}
Thanks, James
"Dennis Myren" <de****@oslokb.no> wrote in message
news:cW*******************@news2.e.nsc.no... I agree with you, except i disagree with using PascalCasing in parameter
names:
WriteLame(Stream OutputStream, string FullPathAndFilename)
I would rather use camelCasing:
WriteLame(Stream outputStream, string filename)
Well, that is my opinion anyway.
Your's, the MSDN naming conventions, and *many* others. Camel casing
parameters is probably as close to standard as you are going to get.
Yikes! It was just an opinion - uptight much?? :-)
For the record though, the reason I don't like camel casing is because it
makes it look like the first "word" is the data type. In other words, with
hungarian, you have something like strFilename, which is clear. If I saw
fileName - I would be confused, because fileConfig would make me think that
that is a pointer to a File object for the config file.
So - just my $.02 because I find camel casing confusing..
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:%2****************@TK2MSFTNGP15.phx.gbl...
"Dennis Myren" <de****@oslokb.no> wrote in message
news:cW*******************@news2.e.nsc.no...I agree with you, except i disagree with using PascalCasing in parameter
names:
WriteLame(Stream OutputStream, string FullPathAndFilename)
I would rather use camelCasing:
WriteLame(Stream outputStream, string filename)
Well, that is my opinion anyway.
Your's, the MSDN naming conventions, and *many* others. Camel casing
parameters is probably as close to standard as you are going to get.
Daniel O'Connell [C# MVP] wrote: "Dennis Myren" <de****@oslokb.no> wrote in message
news:cW*******************@news2.e.nsc.no...
I agree with you, except i disagree with using PascalCasing in parameter
names:
WriteLame(Stream OutputStream, string FullPathAndFilename)
I would rather use camelCasing:
WriteLame(Stream outputStream, string filename)
Well, that is my opinion anyway.
Your's, the MSDN naming conventions, and *many* others. Camel casing
parameters is probably as close to standard as you are going to get.
Yeah, I knew I was breaking the MSDN's convention in using the all
lowercase, underscore delimited style. I did this consciously, however.
The reason is because I grew up on Perl, and that community's style
preference tends to be this way. I submitted a CPAN module and found
(and got used to): classes start uppercase, methods are lowercase and
underscored. I am not using this style entirely in aumplib, but I have
definitely been influenced by it. I prefer not having to use my Shift
key all that much. Maybe I won't get away with it in C#, I don't know.
The style preference seems fairly entrenched (much like Perl's is on the
opposite spectrum). We'll see.
As for short variable names, I wasn't trying to obfuscate, I was just
conserving. I'll check the code and see if I can be a little more
enlightening in my variable names. I appreciate the comments (I'm glad
I'm hearing about syntax rather than construct errors).
<gi***@arbingersysBADSPAMBOT.com> wrote in message
news:en**************@TK2MSFTNGP15.phx.gbl... Daniel O'Connell [C# MVP] wrote:
"Dennis Myren" <de****@oslokb.no> wrote in message
news:cW*******************@news2.e.nsc.no...
I agree with you, except i disagree with using PascalCasing in parameter
names:
WriteLame(Stream OutputStream, string FullPathAndFilename)
I would rather use camelCasing:
WriteLame(Stream outputStream, string filename)
Well, that is my opinion anyway.
Your's, the MSDN naming conventions, and *many* others. Camel casing
parameters is probably as close to standard as you are going to get.
Yeah, I knew I was breaking the MSDN's convention in using the all
lowercase, underscore delimited style. I did this consciously, however.
The reason is because I grew up on Perl, and that community's style
preference tends to be this way. I submitted a CPAN module and found (and
got used to): classes start uppercase, methods are lowercase and
underscored. I am not using this style entirely in aumplib, but I have
definitely been influenced by it. I prefer not having to use my Shift key
all that much. Maybe I won't get away with it in C#, I don't know. The
style preference seems fairly entrenched (much like Perl's is on the
opposite spectrum). We'll see.
I will say you probably will not get away with it. Personally I would *not*
use your library simply because its naming conventions are so at odds with
those I am used to. It makes the library seem written by someone who does'nt
know what he's doing.
While I understand you are used to perl's naming conventions, those *are*
perl's naming conventions and are not a very good choice in a platform that
doesn't use them.
Anyway, while I can see you're worried about shift key, a good number of
characters you have to use commonly in C# code require shift, inclufing _.
Whats the difference in typing
something_else and somethingElse? Same number of shift presses, after all.
You classes should be clearer too, ;). Avoid using abbreviations when you
can avoid it.
As for short variable names, I wasn't trying to obfuscate, I was just
conserving. I'll check the code and see if I can be a little more
enlightening in my variable names. I appreciate the comments (I'm glad I'm
hearing about syntax rather than construct errors).
I guess the general gist of what people are saying is that "when in Rome, do
as the Romans do".. when you are writing perl, use that style, when you're
using C#, use a Microsoft-ish style..
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...
<gi***@arbingersysBADSPAMBOT.com> wrote in message
news:en**************@TK2MSFTNGP15.phx.gbl... Daniel O'Connell [C# MVP] wrote:
"Dennis Myren" <de****@oslokb.no> wrote in message
news:cW*******************@news2.e.nsc.no...
I agree with you, except i disagree with using PascalCasing in parameter
names:
WriteLame(Stream OutputStream, string FullPathAndFilename)
I would rather use camelCasing:
WriteLame(Stream outputStream, string filename)
Well, that is my opinion anyway.
Your's, the MSDN naming conventions, and *many* others. Camel casing
parameters is probably as close to standard as you are going to get.
Yeah, I knew I was breaking the MSDN's convention in using the all
lowercase, underscore delimited style. I did this consciously, however.
The reason is because I grew up on Perl, and that community's style
preference tends to be this way. I submitted a CPAN module and found (and
got used to): classes start uppercase, methods are lowercase and
underscored. I am not using this style entirely in aumplib, but I have
definitely been influenced by it. I prefer not having to use my Shift key
all that much. Maybe I won't get away with it in C#, I don't know. The
style preference seems fairly entrenched (much like Perl's is on the
opposite spectrum). We'll see.
I will say you probably will not get away with it. Personally I would
*not* use your library simply because its naming conventions are so at
odds with those I am used to. It makes the library seem written by someone
who does'nt know what he's doing.
While I understand you are used to perl's naming conventions, those *are*
perl's naming conventions and are not a very good choice in a platform
that doesn't use them.
Anyway, while I can see you're worried about shift key, a good number of
characters you have to use commonly in C# code require shift, inclufing _.
Whats the difference in typing
something_else and somethingElse? Same number of shift presses, after all.
You classes should be clearer too, ;). Avoid using abbreviations when you
can avoid it.
As for short variable names, I wasn't trying to obfuscate, I was just
conserving. I'll check the code and see if I can be a little more
enlightening in my variable names. I appreciate the comments (I'm glad
I'm hearing about syntax rather than construct errors).
"Drebin" <th*******@hotmail.com> wrote in message
news:Y7*****************@newssvr15.news.prodigy.co m... I guess the general gist of what people are saying is that "when in Rome,
do as the Romans do".. when you are writing perl, use that style, when
you're using C#, use a Microsoft-ish style..
Certainly a good way to put it. Doing anything else will probably just
confuse people. I imagine perl people would be aggervated and make mistakes
with code written in .NET style just as I am with code written in perl's
style(of course, just writing in perl aggervates and confuses me, ;).
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...
<gi***@arbingersysBADSPAMBOT.com> wrote in message
news:en**************@TK2MSFTNGP15.phx.gbl... Daniel O'Connell [C# MVP] wrote:
"Dennis Myren" <de****@oslokb.no> wrote in message
news:cW*******************@news2.e.nsc.no...
>I agree with you, except i disagree with using PascalCasing in
>parameter names:
>WriteLame(Stream OutputStream, string FullPathAndFilename)
>I would rather use camelCasing:
>WriteLame(Stream outputStream, string filename)
>
>Well, that is my opinion anyway.
>
Your's, the MSDN naming conventions, and *many* others. Camel casing
parameters is probably as close to standard as you are going to get.
Yeah, I knew I was breaking the MSDN's convention in using the all
lowercase, underscore delimited style. I did this consciously, however.
The reason is because I grew up on Perl, and that community's style
preference tends to be this way. I submitted a CPAN module and found
(and got used to): classes start uppercase, methods are lowercase and
underscored. I am not using this style entirely in aumplib, but I have
definitely been influenced by it. I prefer not having to use my Shift
key all that much. Maybe I won't get away with it in C#, I don't know.
The style preference seems fairly entrenched (much like Perl's is on the
opposite spectrum). We'll see.
I will say you probably will not get away with it. Personally I would
*not* use your library simply because its naming conventions are so at
odds with those I am used to. It makes the library seem written by
someone who does'nt know what he's doing.
While I understand you are used to perl's naming conventions, those *are*
perl's naming conventions and are not a very good choice in a platform
that doesn't use them.
Anyway, while I can see you're worried about shift key, a good number of
characters you have to use commonly in C# code require shift, inclufing
_. Whats the difference in typing
something_else and somethingElse? Same number of shift presses, after
all.
You classes should be clearer too, ;). Avoid using abbreviations when you
can avoid it.
As for short variable names, I wasn't trying to obfuscate, I was just
conserving. I'll check the code and see if I can be a little more
enlightening in my variable names. I appreciate the comments (I'm glad
I'm hearing about syntax rather than construct errors).
Drebin <th*******@hotmail.com> wrote: I guess the general gist of what people are saying is that "when in
Rome, do as the Romans do".. when you are writing perl, use that
style, when you're using C#, use a Microsoft-ish style..
Exactly right. Personally I find this also helps me to think in C#
idioms rather than the idioms of whatever language I'd be tempted to
use the naming conventions of. Trying to use one language as if it's
another is never a good idea.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Gilad,
Please don't take offense, this is really just a lesson-learned (for me
too!) that your "interface" to developers is KEY.. it's equally important
than if your code actually works. Imagine I had DLL's that methods like
gftgd(int x, int n) - having your "interface" be self-describing and
self-documenting turns out to be dare-I-say critical to the success of your
library.
And for the comment of "wouldn't you just shrug it off" - the answer is no.
I've run across many confusing and poorly documented libraries - and at some
point, it's just easier for me to write it myself. I think "I don't want to
rely heavily on this object that doesn't make much sense to me".
You asked for constructive criticism, and you got it - but this has been a
good lesson to everyone. I don't think I've ever thought this much about my
developer interface. So - thanks!! :-)
"gilad" <gi***@discussions.microsoft.com> wrote in message
news:97**********************************@microsof t.com... "gi***@arbingersysBADSPAMBOT.com" wrote:
Hi, I have just released the initial beta of a C# project called
'aumplib'...
Thanks everyone for the feedback. I didn't really want to start an
impassioned debate about the code's naming convention. I guess this was
good--I've found how important the style is to people. I hadn't really
taken much thought about it, worrying myself mostly with the function of the
code. Fortunately, I consider this a pretty easy fix so it shouldn't be hard to
conform. (Then maybe I can get some comments about whether the logic of
the code works or not ;)
Drebin wrote: Gilad,
Please don't take offense, this is really just a lesson-learned (for me
too!) that your "interface" to developers is KEY..
None taken. Ultimately, this has helped. I *do* want my library to be
used, and if it takes making aesthetic changes, then that's a small
price to pay.
"gilad" <gi***@discussions.microsoft.com> wrote in message
news:8F**********************************@microsof t.com... "Daniel O'Connell [C# MVP]" wrote:
I will say you probably will not get away with it. Personally I would
*not*
use your library simply because its naming conventions are so at odds
with
those I am used to. It makes the library seem written by someone who
does'nt
know what he's doing.
But if you were a programmer who seriously needed the functionality of the
library, would you still balk at the style? It doesn't seem likely. You'd
Not if it was vital, though I would probably fire off a courtesy email to
the maintainer suggesting he learns proper naming conventions.
However, except in the rare case that a library is the only available that
supports something, I certainly would turn it down in favor of a competitor
that followed conventions.
probably shrug your shoulders and shake your head, and use it. And as for
it
having the appearance of being "written by someone who does'nt know what
he's doing", isn't the actual code logic going to tell this rather than
the
style? If I'm doing everything correctly as far as interfacing the DLLs,
construction of objects, etc, and yet decide to use a slightly different
naming convention (because it is style we're talking about here isn't
it?),
doesn't that say whether or not I "know what I'm doing"? Breaking a style
convention could also be considered being a 'rebel'.
It could be considered a rebellion, but more times than not its simply
"Damn, this guy didn't even bother reading the most basic document". If you
couldn't be bothered to read a styles document, why should I think you took
the time to learn initalization, property, and event patterns?
For the record, I know you have read it, but that is the appearance that is
often taken from code that is not named along with standard style. While I understand you are used to perl's naming conventions, those *are*
perl's naming conventions and are not a very good choice in a platform
that
doesn't use them.
Like I said, I was influenced by this style convention, not using it
explicitly. And I have alternated the Perl style in my own projects when
it
suited me. Only when I have submitted to a repository like CPAN have I
conformed entirely. (Largely because the hue and cry that rang out from
there
when I didn't.)
Within your own code, its one thing, but for open source projects
especially, you should look into using standard conventions. 90%+ of users
are going to expect those conventions, meaning some potential contributers
aren't going to contribute due to style alone(if its bad enough, I won't
even bother tryign to dechiper it). Anyway, while I can see you're worried about shift key, a good number of
characters you have to use commonly in C# code require shift, inclufing
_.
Whats the difference in typing
something_else and somethingElse? Same number of shift presses, after
all.
You got me there. I do use underscores. But I only do it where I need to
separate words for clarity (what I consider clarity anyway), so a lot of
my
variables were pretty short and without the underscore (which seems to
draw a
lot of criticism too; see below). The convention of C# uses long names
most
times, and at least have one shift operation for every named thing.
One of the many code clarity guidelines: Use variables that mean something.
LOL. Its just an expectation of good code.
Personally, I use short, but complete variable names. When I'm dealing with
just one array or somesuch, I will use just
int index;
or
int count; (depending). But if the method has a couple of indexers or loops,
I'll do
int charIndex;
int stringIndex;
int charCount;
int stringCount;
or what have you.
Parameters should be fairly clear, but I don't think they should be too
long. XML docs should be the primary source of information about a
parameter, not its name. You classes should be clearer too, ;). Avoid using abbreviations when you
can avoid it.
Sigh. I like abbreviations. So short, so succinct... Okay, thanks for the
comments.
Yes, very short...but when I don't know what they mean, they become a
difficult issue for me. So using abbreviations for uncommon terms is a bad
idea. You have to remember that your user isn't going to know everything
about audio and they do not want to have to refer back to docments every
time they run across an abbreviation they don't know off hand.
"Daniel O'Connell [C# MVP]" wrote: I will say you probably will not get away with it. Personally I would *not*
use your library simply because its naming conventions are so at odds with
those I am used to. It makes the library seem written by someone who does'nt
know what he's doing.
But if you were a programmer who seriously needed the functionality of the
library, would you still balk at the style? It doesn't seem likely. You'd
probably shrug your shoulders and shake your head, and use it. And as for it
having the appearance of being "written by someone who does'nt know what
he's doing", isn't the actual code logic going to tell this rather than the
style? If I'm doing everything correctly as far as interfacing the DLLs,
construction of objects, etc, and yet decide to use a slightly different
naming convention (because it is style we're talking about here isn't it?),
doesn't that say whether or not I "know what I'm doing"? Breaking a style
convention could also be considered being a 'rebel'.
While I understand you are used to perl's naming conventions, those *are*
perl's naming conventions and are not a very good choice in a platform that
doesn't use them.
Like I said, I was influenced by this style convention, not using it
explicitly. And I have alternated the Perl style in my own projects when it
suited me. Only when I have submitted to a repository like CPAN have I
conformed entirely. (Largely because the hue and cry that rang out from there
when I didn't.)
Anyway, while I can see you're worried about shift key, a good number of
characters you have to use commonly in C# code require shift, inclufing _.
Whats the difference in typing
something_else and somethingElse? Same number of shift presses, after all.
You got me there. I do use underscores. But I only do it where I need to
separate words for clarity (what I consider clarity anyway), so a lot of my
variables were pretty short and without the underscore (which seems to draw a
lot of criticism too; see below). The convention of C# uses long names most
times, and at least have one shift operation for every named thing.
You classes should be clearer too, ;). Avoid using abbreviations when you
can avoid it.
Sigh. I like abbreviations. So short, so succinct... Okay, thanks for the
comments.
"gi***@arbingersysBADSPAMBOT.com" wrote: Hi, I have just released the initial beta of a C# project called
'aumplib'...
Thanks everyone for the feedback. I didn't really want to start an
impassioned debate about the code's naming convention. I guess this was
good--I've found how important the style is to people. I hadn't really taken
much thought about it, worrying myself mostly with the function of the code.
Fortunately, I consider this a pretty easy fix so it shouldn't be hard to
conform. (Then maybe I can get some comments about whether the logic of the
code works or not ;) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Shelly |
last post by:
I had a problem with uploading images in that some files did not have a type
of "image/something" from the
$_FILES which I used for my verification.
Someone (THANK YOU) suggested using...
|
by: TheAd |
last post by:
At this moment I use MsAccess and i can build about every databound
application i want. Who knows about a serious open source alternative?
Because Windows will be a client platform for some time, i...
|
by: gilad |
last post by:
This is to announce the beta 2 release of Aumplib. After garnering
comments from this newsgroup, I have modified the code to use a more
standard style convention.
Aumplib is a C# namespace which...
|
by: ray well |
last post by:
hi,
i'm looking for a .net audio player control, that can play wav, mp3, and
some
other common formats. i need to plays some audio in my app.
i'm not looking for any whole audio studio, just...
|
by: Lucas Tam |
last post by:
Hi all,
Does anyone has a recommendation on a good audio utility?
Something that will play back audio files of various formats and perhaps do
transformation too?
I found BASS DLL which...
|
by: Nuno Magalhaes |
last post by:
Is there any way to encode a byte stream of audio data into GSM or
other codec data, and the decode also?
I searched all over the Internet and didn't find any valid solution
applying to C#.
I'm...
|
by: Udhay |
last post by:
How to get the frequency of an audio file and how to separate the low
and high frequency of an audio file
|
by: Jordan S. |
last post by:
I would appreciate your thoughts and opinions on the following:
I am looking to render documents into
multiple document formats. At a minimum the documents will need to be
rendered as HTML, and...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
