>I would like to ask about situation in Linux about one problem.
>Does Linux kernel or Alsa drivers supports IEEE 1394 standart?
>
>If yes, could you recomend me some references and advices to be able to =
>use it
>and program it to create applications with IEEE 1394?
>
>If no, could you recomend me some advices or some documentation to be =
>able
>to create IEEE 1394 driver?
for audio+MIDI, there is no fully-defined standard yet. linux already
has a compliant 1394 driver, but you normally need extra protocols on
top of this for moving specific kinds of data around. IEEE has defined
one (IEC61883-6) for audio+MIDI, based on mLAN, and I believe you can
get the specs from them or the AES.
However, it doesn't support any connection management, so all
endpoints have to be explicitly identified by the user, and everything
has to be explicitly delivered. Yamaha submitted their scheme for CM
to the 1394 trade association as the "AV/C Music Subunit". its been
released but not implemented (even by Yamaha) because Yamaha are
changing mLAN again. Basically, to quote from someone who really knows
this stuff:
"So a streaming driver using a format compatible with mLAN devices is
not a problem at this stage - it is possible to direct audio/MIDI to
mLAN devices and pick up audio and MIDI, but not in a flexible
manner. The connection management architecture first needs to settle."
--p
ps. just a quick note to point out that whether you know it or not, the
email program you are using is sending out copies of your mail in both
plain text and HTML formats. increasingly on the net, there are
filters being put in place that silently dump HTML-formatted
email. some mailing lists will not ever accept such posts. as long as
you do this, you are (1) wasting network bandwidth by sending messages
that are typically more than twice as long as they could be (2) making
it harder for people using traditional email readers to read them (3)
risking the chance that people will never see your mail because its
filtered before reaching their email inbox.
On Thu, Feb 13, 2003 at 02:34:01 +0200, Pavel wrote:
> Hi,
> I would like to ask about situation in Linux about one problem.
> Does Linux kernel or Alsa drivers supports IEEE 1394 standart?
The Linux kernel supports it, and the is even some basic support for 1394
audio (in or out only, I forget which).
The audio protocol is called A+M (audio + MIDI), and there is a connection
mangement layer over the top, but there are some licencing issues with
that.
Mark Knecht has been working on somehting along these lines and I have
been collecting documentation for a while, and wront some very simple test
code, but never tested it.
- Steve
I e-mailed the list a couple of days ago asking for some advice
regarding my RTMix app ("how to make it more user-friendly"). I am still
waiting for some help on this one :-D. Again, any insight is greatly
appreciated!
Sincerely,
P.S. Web server hosting my page is still down, thanks to the "smart"
university technicians... If someone desires screenshots I'd be more
than willing to send them to you as an attachment (I just don't wanna do
that over the mailing list because it would clutter a lot of people's
inboxes).
Ico
On Wed, 2003-02-12 at 09:49, Paul Davis wrote:
> >If you are interested, I am sure people would pay for binaries of
> >ardour.I would. I know other musicans that would.I could get more
> >musicans to. Personally, I have been waiting for it since I first heard
> >about it. Why not release something?
>
> because i am tired of downloading open source projects that are still
> so clearly under development. i am tired of the impression that this
> creates. when i get hold of something like freqtweak, which i can
> compile or get binaries for, and the thing just works ... that is the
> right impression. the wrong impression comes from stupid bugs,
> inability to cleanly exit the program (still a core problem with
> ardour), and functionality that is obviously necessary and either
> missing or incomplete.
ahhh, you are a perfectionist! I see your point. Open source software is
always under dev, unless it's not maintained. You _could_ release
'alpha' versions clearly stating that it is alpha condition.
>
> People are waiting! Most open
> >source projects release binaries throughout their development phase.
> >Instead of adding cool new features for years on end, why not release
> >something that musicans can use.
>
> that's precisely what i am trying to do. however, my definition of
> "something that musicians can use" might be different from yours.
Well, obviously, ardour isn't at the 'release' stage, but perhaps beta
or even alpha. Perhaps someone else with more time, could release a
binary version for you. Pick one or two target dists, and release alpha
binaries or such. You'd certainly get more bug reports. :)
> jazz++ has been around for a long time, and is available as a
> binary. why isn't it widely loved and used? because it really isn't
> very good. i know that i tried to use it many times, and found it,
> well, frankly i found it completely awful.
> ardour still has lots of significant bugs and a few design issues that
> need addressing before i want the general population judging it. to
> release ready-to-run copies now, or even tarballs that would help
> people who can't/won't use CVS to try to compile it ... well, all i
> think it would do is to increase the number of people who have "been
> there, don't want to go back" with respect to the program.
Personally, I keep checking back to projects that are in some kind of
beta stage, or too buggy to use and look interesting, to see what things
have changed. Heck, I'll even use software day to day that crashes
constantly, if I think it's useful enough. (mozilla - early stages comes
to mind)
> when ardour is in a state where i believe (rightly or wrongly) that a
> reasonably typical target user can sit down and just use it without
> encountering bugs when recording a typical 12-32 track piece, there
> will be binaries.
People are willing now to support you financially now, Paul.Paypal might
be a good idea, if you dont mind begging till ardour is at a point where
you can release to the general public.
> --p
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
--
My cat's a debugger....
Potter, Lorn, "ljp"
core developer / Web Administrator
Project OPIE- the Open Palmtop Integrated Environment
http://opie.handhelds.org | http://www.opie.info (german) |
http://www.opie.us
IRC: irc.freenode.net #opie #opie.de
llornkcor(a)handhelds.org
llornkcor(a)helixcommunity.org
-----Forwarded Message-----
From: Son of Zev <sonofzev(a)labyrinth.net.au>
To: linux-audio-dev(a)music.columbia.edu
Cc: Alsa-dev <
Thanks Vincent.
Your reply is appreciated.
However I have been involved in the ardour lists for over 2 years. I
have spent much time reading about potential problems and responded to
all those that have had the courtesy to respond. I have also learnt and
spent much time investigating problems that have nothing to do with the
production of music.. simply to try and help developers iron out
problems.. Credit goes to some who have especially Takashi Iwai, Robert
Jonsson, Tommi Ilmonen and a few others.
If you look back into archives a couple of years back alot of
development into inclusion of MIDI sync was added to some softwares
(especially MusE) to accomodate users like myself who depend on this
sync to make software compatible with real studios.
BUT. In the last few weeks I have spent much time into trying to
configure and compile ardour (the potentially greatest audio recording
software available to us) but all my responses after I sent an opinion
to the string "ahem" concerning Steinberg having produced (but not
released) versions of their commercial softwares under our much loved
platform, have been completely ignored.. except this one..
My responses have not been ignorant nor lacking in information. As I
mentioned I have spent much time learning about the Linux platform and
contributing when I can ...
My annoyance is when it was asked of me to provdie more information and
I did .. no response came.. then when I tried to resolve it myself and
no further response came that's when I could only put 2 & 2 together and
see that a response I made to the string "ahem" could have been related
cheers
Allan
On Thu, 2003-02-13 at 00:50, Vincent Touquet wrote:
> I'm not a "real coder" either (so one might argue I shouldn't be on
> linux-audio-dev, but I'm just interested in the discussions), so I think
> I understand the root cause of your grief.
>
> I think if (if) the Ardour developers are _expecting_ quality feedback
> from normal users (not just programmers) at this stage, they should
> provide tarballs of the stable CVS snapshots they want to be tested.
>
> But maybe they want to wait for 1.0 before letting endusers test it?
> In that case, maybe you tried to use it too early in its development ?
> I think they honestly appreciate your effort to participate, there
> should be no doubt about that, but maybe Ardour is still changing too
> rapidly for you to be able to track it.
>
> I think only the developers of Ardour can clear out this question.
>
> best regards,
> Vincent
Dear Sir,
My name is William Ume,
Presently,I am working in an African country.
I got your contact via the internet and felt you may be willing to pursue this with me.
This proposal may sound strange to you or probably you may even think it is a joke,because of lots of funny mails circulating over the internet .Well if you do,I really understand,but honestly my freind,I am really handicaped,because this is the only means available to me to cominicate to you.
Honestly ,I think you should give me a trial,I need your assistance and the deal is good.
The deal involves the transfer of $45million,safely intoyour account, and for this you are to receive 20% of the fund.
If you are intereted in pursuing this further please contact me via e-mail so that I can furnish you with the relevant detail about the origin of the fund and the modalities for the deal.
Please send your response to my e-mail address.
William.
En ucuz lensler icin lutfen tiklayin.
Bir telefonla adrese teslim.
http://www.akdenizgoz.com
Akdeniz Goz Merkezi
Fevzipaþa No:73 Fatih 0 212 635 74 74
Listeden cikmak icin remove(a)akdenizgoz.com adresine bos mail gonderiniz
Does anyone keep an actual list of required features with motivations?
If not, it might be a good idea to start writing one. We tend to stay
very technical around here, and the required feature set is more or
less something we "maintain" by guarding our own pet features. This
might work for us, but it's probably better to make an official,
prioritized list.
We can use it for XAP of course, and - which is why I had the idea of
writing this post - we could throw it into the GMPI discussion.
BTW, the GMPI list is up now, and there's already some traffic on it.
Consider joining if you haven't had enough of plugin API discussion
already. ;-)
http://www.freelists.org/cgi-bin/list?list_id=gmpi
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
This release includes lots of bugfixes to improve stability and
several new features:
* Added grid and grid-snap features. The grid spacing is
adjustable on each module.
* Added reference tempo (bpm) parameter for the Delay Time grid
calculation. It includes units based on both msec and beats.
This allows for much easier rhythmic manipulation if you know
the bpm.
* Pitch now uses semitones as units
* Adjustable maximum delay time choices (up to 20 seconds)
* Min/max legend text on plots. Thus you can see where you are
zoomed (zoom with Ctrl-Alt-Shift left-drag)
* Changing FFT sizes on the fly now stable
* Fixed many nasty crashing bugs
http://freqtweak.sourceforge.net/
Happy tweaking,
jlc
Hi all,
I am in the process of revamping my app as well as adding more features.
The problem my app currently has is that the main window is not
resizable, which may potentially cause problems on displays with limited
resolution. I've decided to fix this issue once and for all but am not
sure which path to take. The app in question is RTMix and its current
layout is split into two parts:
Top with timers and buttons
Bottom with the main notification widget and bunch of tabs for editor
and other functionalities.
The app looks something like this:
_________
|buttons|
| timer |
_________
| tabs |
|widgets|
_________
Now I am ready to begin working on a resizable version (which should
mostly not be a problem, other than being time-consuming) and am
wondering whether I should separate the two widgets all together and
have them therefore fully customizable (size-wise). While this option
seems very easy to implement and also attractive, I am concerned with
the issue that the app will easily lose its default looks and may
quickly become overwhelming for the first-time user (since it is
designed to provide performer-computer interface with the least amount
of familiarization required). I would especially appreciate comments
from people who got to use RTMix as to what would they like to see, but
of course I would appreciate anyone else's opinions on this matter as
well.
The other option I've been thinking is to move the two widgets
side-by-side, rather than having one over the other, which would
certainly make maximizing window easier and would utilize the desktop
space more efficiently. However, the issue is also that the app has a
bunch of other deployable floating sub-windows and as such this may not
prove to be the best solution, and would probably look pretty useless
when having a relatively small window.
Finally, I can simply leave the app as it is but then the notification
interface (the bottom part) as well as other tabbed widgets of the
bottom part (such as the script editor) will not be as efficient in
utilizing the desktop space as they could possibly be.
I also thought of having the two widgets designed in such a way that
they can be "glued" together (i.e. xmms-like) or separated as needed,
but I am just afraid that this option may take too much effort since
then I would have to get rid of the default window decorations (in order
to make them "gluable") and make my own custom-designed window handles,
which seems too much of a nuisance to implement.
I am sure someone might have yet another idea regarding this issue that
I am simply unable to think of so I would greatly appreciate your input
on this matter.
The bottom line is that I am looking to make this app as flexible in
terms of desktop space utilization as possible while sacrificing the
minimum amounts of the "standardization" it currently has to offer.
Your help is greatly appreciated! BTW I am using Qt (if that becomes
relevant at some point).
P.S. I have a bunch of screenshots on my site, but the network is
currently screwed up on the University campus so it may end up not being
available for the next 8-24 hrs. Hence, I am unable to give you the
screenshots. However, you may wanna try the URL in my sig -- who knows,
maybe the network will be up by the time this hits your inboxes :-).
Again thanks for your help! Sincerely,
Ivica Ico Bukvic, composer, multimedia sculptor,
programmer, webmaster & computer consultant
http://meowing.ccm.uc.edu/~ico
============================
"To be or not to be" - Shakespeare
"To be is to do" - Socrates
"To do is to be" - Sartre
"Do be do be do" - Sinatra
"2b || ! 2b" - ?
"I am" - God