Re: JMF external MIDI support?

[Matthias Pfisterer]

Hi,

this is a mailing list about Java Sound. There is also a mailing list
about JMF. Nevertheless, you asked on the right list. JS can be
considered part of JMF, or not. JMF can work without JS, but if you use
the "performance pack" version, JS is included (and used). JS is also
part of the jdk, starting with version 1.3.

The real difference is that JS is a more low-level API, where JMF is a
high-level one. If you want to do serious MIDI work (means beyond
playing a MIDI file), I recommend using JS directely. It allows you to
manipulate data on the MIDI event level. So in the following I will
speak about Java Sound.

Now to your question: The Sun implementation of JS does not really deal
with external MIDI. It tries to do, but it is not in a usable state.
That's the bad news. The good news is that there is an alternative JS
implementation called Tritonus that supports the ALSA sequencer, giving
you external MIDI support.

Have a look at http://www.tritonus.org/

the version 0.3.0, though called a development version, is quite stable
and supports ALSA 0.5.X. So this is the one for you. Playback of MIDI
files to external ports is well-tested, besides some problems related to
sysex events. Input from the "raw" MidiDevices is working, too. Not yet
implemented is capturing using the Sequencer object of Java Sound.

If you want to switch to ALSA 0.9.X, use the development state of
Tritonus from its cvs repository. Sequencer related parts should work;
PCM is in the middle of a major rehack and may be uncompilable.

For further questions on Tritonus, please use the tritonus-user or
tritonus-devel maling lists.


Matthias


"em@nuel" wrote:
> 
> Hi,
> 
> I'm new to this list.  I'm just starting to experiment with JMF on
> Linux, and I haven't found in any documentation whether external MIDI
> devices are supported.  Is this the right place to ask about this?
> 
> I'm using the ALSA drivers with OSS emulation.  ALSA midi players work
> fine, as do OSS midi players, but JMF does not appear to detect any
> external MIDI devices.
> 
> Here's the output of a little program I wrote that prints out the
> results of MidiSystem.getMidiDeviceInfo():
> 
> 0: description=Software wavetable synthesizer and receiver, name=Java Sound 
>Synthesizer, vendor=Sun Microsystems, version=Version 1.0
> 1: description=Software sequencer / synthesizer module, name=Java Sound Sequencer, 
>vendor=Sun Microsystems, version=Version 1.0
> 
> This program detects all the right MIDI devices when I run it on
> Windows.
> 
> If I play a MIDI file from jmstudio, it's played using the software
> synth.
> 
> So my question is: does JMF for Linux support external MIDI devices
> (or, more generally, non-software synth MIDI devices)?
> 
> If so, any tips on getting it to detect the device?  If not, I'll
> probably write a driver for ALSA.
> 
> Thanks for any help!
> 
> Versions:
> alsa-driver-0.5.11
> j2sdk-1.3.0-FCS-linux-i386
> jmf-for-java2-2.1.1-fcs-linux-i386
> linux-2.4.4
> 
> Using ALSA's ymfpci driver.
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
Matthias Pfisterer  

Take into account
that great love
and great achievements
involve greak risk.

 (from a nepalese mantra)

Java Sound Examples:
http://www.jsresources.org/jsexamples-old/
Tritonus, the open source implementation of the Java Sound API:
http://www.tritonus.org/
--


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: Re: Java/Linux at JavaOne

[Jesus M. Salvo Jr.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 31 May 2001 08:24, Christopher Smith wrote:
> On 31 May 2001 06:45:08 +1000, Jesus M. Salvo Jr. wrote:
> > > 4) Use JNI to use Linux's various asynch I/O API's.
> >
> > Option 4) is how BEA WebLogic Server does it, ( I think ). They have this
> > libmuxer.so ( which is also available for Solaris -- dont know why when
> > JVM for Solaris makes use of solaris native threads ) which enables
> > native I/O, or the so-called "performance pack".
>
> Yes, many of the various application servers employ various strategies
> for this. Unfortunately I am unaware of any of them who have taken the
> time to do this for Linux.
>

 apart from BEA WebLogic Server which I can confirm. Although they 
support WLS 5.1 on linux, they only started supporting native I/O for Linux 
with WLS 6.0.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjsWJeYACgkQAvd5SY4qWYzHgACcCs3bVTBAKZsY1o7Z2vlScE2h
4jcAoKxibMnhRUCKyBOCnUVJsiBGU+qp
=o0sa
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Session en Tomcat

[Pablo Trujillo]

Buenos días amigos,
Estoy necesitando su ayuda con respecta a Java y en particular con las
Servlet.
Necesito información sobre como trabajan las servlet con las sesiones,
necesito saber como se asigna el Id para cada sesión y donde se almacenan
las cookies que contienen esta información en la máquina del cliente.
Espero que alguien pueda ayudarme.
Desde ya muchas gracias
PAblo


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Servlet Source

[Pablo Trujillo]

Otra vez yo,
Alguien conoce donde se puede encontrar el codigo (.java) de la librería
Servlet.jar
-
Click here for Free Video!!
http://www.gohip.com/free_video/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: Session en Tomcat

[Rajendra Kumar Komandur]

Title: RE: Session en Tomcat





Please Send Mails in Engilsh


Komandur Rajendra Kumar
Sr.Software Engineer
Silverline Wireless Practice
> Phone: 3240189 Extn. 4621
> HotLine 732-362-5828



-Original Message-
From: Pablo Trujillo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 31, 2001 5:23 PM
To: Java-Linux
Subject: Session en Tomcat



Buenos días amigos,
Estoy necesitando su ayuda con respecta a Java y en particular con las
Servlet.
Necesito información sobre como trabajan las servlet con las sesiones,
necesito saber como se asigna el Id para cada sesión y donde se almacenan
las cookies que contienen esta información en la máquina del cliente.
Espero que alguien pueda ayudarme.
Desde ya muchas gracias
PAblo



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Session en Tomcat

[Diego Pons]

Pablo Trujillo wrote:
> 
> Buenos días amigos,
> Estoy necesitando su ayuda con respecta a Java y en particular con las
> Servlet.
> Necesito información sobre como trabajan las servlet con las sesiones,
> necesito saber como se asigna el Id para cada sesión y donde se almacenan
> las cookies que contienen esta información en la máquina del cliente.
> Espero que alguien pueda ayudarme.
> Desde ya muchas gracias
> PAblo

Depende de qué servidor uses. Para Tomcat, consultá la documentación en
http://jakarta.apache.org (el que yo uso).

En general, los cookies de las sesiones son temporales, en Netscape no se
guardan en el disco (creo). En Tomcat hay un ejamplo de cómo leerlos.

De paso, ¿hay alguien que provea un newsfeed gratis en Uruguay?

-- 
Diego Pons Pharos Consulting LLC
[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

CSS file and Servlet

[Messias]

 filename="text1.rtf"

method ValueUnBound

[Pablo Trujillo]

When I create a session I add several elemetos to it, those which access
from different classes, however when I close the session and the method
ValueUnBound is executed I can not access to these elements. Why?.

-
Click here for Free Video!!
http://www.gohip.com/free_video/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CSS file and Servlet

[Nathan Meyers]

Messias wrote:

> Hi all,
> I'd like to know if it's possible to use .css file with servlets and if
> it's, how can I do it ?
> TIA,
> Messias

A .css is (usually) just a file. Your servlet engine needs to be
configured to serve up files, and you need to place the .css somewhere the
servlet engine can serve it up.

Nathan


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Session en Tomcat

[Diego Pons]

> Rajendra Kumar Komandur wrote:
> 
> Please Send Mails in Engilsh

You too :-)

-- 
Diego Pons Pharos Consulting LLC
[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CSS file and Servlet

[Luca Aurel]

Have you tried and it didn't work ?
I'm using .css in JSPs without any problem (and JSPs are converted into
servlets, so ...)
Just use it as you'd  normally use them in plain HTML.
I mean, like this:


PrintWriter out=response.getWriter();
// print HTML tags (, , etc...)
out.println("");

, where main.css is the .css file
Hope it helps.

Luca

- Original Message -
From: "Messias" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 31, 2001 5:43 PM
Subject: CSS file and Servlet


Hi all,
I'd like to know if it's possible to use .css file with servlets and if
it's, how can I do it ?
TIA,
Messias


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Familiar] Blackdown for 0.4

[Thomas Enderes]

Thanks, now I have configured the familiar distribution to use the old 
Xfree.
Now the Blackdown port works for the biggest part:

I can start my Java application, buttons work,
but I can not enter text, neither with scribble nor with the
virtual keyboard (works fine for non-java apps).
I could not find out what the problem is: Xfree with twm ? Blackdown 
port ? Any thoughts ?


Jim Gettys wrote:

> I think that Xp is the X print stuff...
> 
> Best would be to recompile not to need it (seems unlikely you'll be
> printing to me).
> 
> Or try a binary off of the Skiffs or sharks for the library.
> libXp.so.6.2 isn't all that big (30Kbytes).
>   - Jim
> 
> --
> Jim Gettys
> Technology and Corporate Development
> Compaq Computer Corporation
> [EMAIL PROTECTED]


-- 
Thomas Enderes, Research Engineer, Bell Labs, Lucent Technologies
Tel: +44 1793 775865  E-mail: [EMAIL PROTECTED]
Fax: +44 1793 776725  Web:http://enderes.home.pages.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Java/Linux at JavaOne

[Thomas Enderes]

Hi,

will there be anyone involved with the ARM / iPAQ ports around at the 
JavaOne ?

Thomas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

port that works with iPAQ familiar v0.4

[Thomas Enderes]

Hi,

when I tried to run the jre_v2_arm15a it gave me a not found for called 
libXp.so.
Has anyone recompiled it already ?

Thanks,
Thomas


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: Re: Java/Linux at JavaOne

[ed phillips]

Christopher Smith wrote:

> On 31 May 2001 06:45:08 +1000, Jesus M. Salvo Jr. wrote:
> > > 4) Use JNI to use Linux's various asynch I/O API's.
> > Option 4) is how BEA WebLogic Server does it, ( I think ). They have this
> > libmuxer.so ( which is also available for Solaris -- dont know why when JVM
> > for Solaris makes use of solaris native threads ) which enables native I/O,
> > or the so-called "performance pack".
>
> Yes, many of the various application servers employ various strategies
> for this. Unfortunately I am unaware of any of them who have taken the
> time to do this for Linux.
>
> > Speaking of 4), does anyway have a ready-made ( cut&paste ) C code that one
> > can compile into a shared library and have all I/O made through this library
> > via JNI?
>
> I'll be demoing a library that does this with SGI's KAIO patch at the
> presentation (presuming I can iron out this nasty sigtimedwait problem).
>
> > And how does JDK 1.4 affect the performance on Linux, given that 1.4 was
> > better I/O support overall, in particular non-blocking I/O.
>
> We're benchmarking that right now, but it doesn't take a genius to
> realize the impact is pretty spectacular. All you need to do is compare
> Apache's performance with polling I/O based web servers on Linux to get
> a good idea of the potential performance gains.
>
> The NIO API is a little annoying to me though in that it's low enough
> level that it exposing the polling approach to I/O. With the overhead of
> JNI, it's much nicer to use an asynch I/O approach for most Java
> applications.

Chris,

Thanks for providing this pre-session back and forth.  Although I'm excited by
the
prospects and possibility of say option number 4 over the long haul, I've got to
be concerned as much with stability as scalability.  After all, I've got
to serve actually existing applications in production today. ;-)

So, the green threads or the lots of boxes w/tweaking of the kernel have been the
options
of choice for me and my colleagues.  Some people claim that green threads are not
at all
an option when scaling is your objective, so I'm heartened to see that even as
you are
experimenting with SGI's KAIO patch, you've kept green threads as an option.
I assume you are going to address the tradeoffs of the various options in your
presentation?

I'm interested, you might have gathered, in practical, and as stable as possible,
options for
scaling Java on Linux.

Thanks again,

Ed


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: Re: Java/Linux at JavaOne

[ed phillips]

Christopher Smith wrote:

> On 31 May 2001 10:58:08 -0700, ed phillips wrote:
> > Thanks for providing this pre-session back and forth.  Although I'm excited by
>
> Probably the only way I can get people to show up for 8:30am (someone at
> KeyMedia obviously doesn't like me).
>
> > the prospects and possibility of say option number 4 over the long haul, I've got
> > to be concerned as much with stability as scalability.  After all,
> > I've got to serve actually existing applications in production today.
> > ;-)
>
> Understood. I expect #4 won't be a practical option for another 6
> months. The SGI KAIO patch itself is pretty stable, but the jury is
> still out on my code. ;-) Also, there are kernel developers working on
> their own kernel AIO implementation which is signal free (kills
> portability, but does avoid a ton of hassles with the JVM).
>
> > So, the green threads or the lots of boxes w/tweaking of the kernel have been the
> > options of choice for me and my colleagues.  Some people claim that green threads
> > are not at all an option when scaling is your objective, so I'm
> > heartened to see that even as you are experimenting with SGI's KAIO
> > patch, you've kept green threads as an option. I assume you are going
> > to address the tradeoffs of the various options in your presentation?
>
> The green thread option depends a lot on where you need the scalability.
> As I've said before, in most cases, the scalability need is all about
> I/O performance. Thread-per-I/O has got to be the most inefficient way
> imaginable to represent I/O on a computer. Green threads (and various
> many-to-many thread implementations) get around this (at least from a
> kernel perspective). So they are most definitely a viable option.
> They do, unfortunately, come with some caveats.
>
> > I'm interested, you might have gathered, in practical, and as stable
> > as possible, options for scaling Java on Linux.
>
> I think really most people are. The thing about the Linux world is that
> progress is moving so fast that today's "unstable, untested" feature is
> tomorrows "stable, practical" feature. Heck, I've already had to change
> the slides for this presentation a few times because of progress that
> has been made since I first started putting the presentation together.
> So, I'm going to talk both about what's practical and available here and
> now, but I'm also going to talk about what the future holds. In
> particular, I think if you are starting a project now which will be
> deployed in 6+ months, you have a lot of interesting options to
> consider.
>

Thanks again, Chris. You express well the quandary, if you could call it that, of
choosing the best option when progress is moving so fast.

Ed


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: Re: Java/Linux at JavaOne

[David Brownell]

I may have missed this ... will this be covering GCJ?

Compiled Java has some nice advantages.  Including
more natural and efficient integration with native code,
as well as faster startup and the ability to do some
aggressive ahead-of-time optimizations, and working
better with standard OS tools (RPM etc).

- Dave



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: Re: Java/Linux at JavaOne

[Christopher Smith]

On 31 May 2001 16:09:38 -0700, David Brownell wrote:
> I may have missed this ... will this be covering GCJ?
> 
> Compiled Java has some nice advantages.  Including
> more natural and efficient integration with native code,
> as well as faster startup and the ability to do some
> aggressive ahead-of-time optimizations, and working
> better with standard OS tools (RPM etc).

I will mention this, but so far in my experience GCJ has not produced
terribly optimal code, it's behind in terms of JDK support, and is not
supported by any of the application server vendors. Even Turbo/J seems
to have a tough time beating the more recent IBM & Sun JVM's.

I'm curious about your comment about it working better with RPM. Can you
give me an example of this?

--Chris


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]