JDK-4931400 : Clarify default connections in default sequencer
  • Type: Bug
  • Status: Resolved
  • Resolution: Fixed
  • Component: client-libs
  • Sub-Component: javax.sound
  • Priority: P2
  • Affected Version: 5.0
  • OS: generic
  • CPU: generic
  • Submit Date: 2003-10-02
  • Updated Date: 2017-05-16
  • Resolved Date: 2003-10-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
Other
5.0 b26Resolved
Related Reports
Duplicate :  
Description
The old sequencer automatically connected itself to the default synthesizer's receiver. That was handy, since it wasn't necessary to explicitely get a Synthesizer object, and connect it to the Sequencer. It was also sufficient, because there was only one sequencer, and only one synthesizer available. It was also the only the only way to have a connected sequencer, since the old sequencer did not allow to connect it to arbitrary Receivers.

The new sequencer is implemented correctly, i.e. there is no automatic connection. That'll break almost all programs that use the sequencer (or want to play MIDI files), because people relied on the default connection (to a Receiver instance). Also it's now possible to choose a Receiver from all available ones on the system, not only the Synthesizer. Unfortunately, initializing the sequencer with a default connection is not useful, because there is no way to remove a connection (see below). Transmitters in a sequencer are always added. So you may add explicitely Transmitter which connects to your Receiver of choice, but the default connection will still be there and you'll hear the music on both devices.

Note that the old sequencer is violating in several instances against the specification, and against the intentions of the specification.

As to the missing API for removal of Transmitters from a Sequencer: this is requested in RFE 4931387.


This is the proposed solution:

1) Specify explicitely that the method MidiSystem.getSequencer() will return a Sequencer instance which is automatically connected to the default synthesizer, or with the first MidiDevice which offers a Receiver, if there is no default Synthesizer available. That way we maintain 100% compatibility.

  /**
!  * Obtains the default sequencer, connected to a default Receiver.
+  * The returned Sequencer instance is 
+  * connected to the default Synthesizer. If there is no Synthesizer
+  * available, or the default Synthesizer cannot be opened,
+  * the Sequencer is connected to the default Receiver.
+  * The connection is made by retrieving a Transmitter instance 
+  * from the Sequencer and setting its Receiver.
+  * 
+  * Closing and re-opening the sequencer will restore the 
+  * connection to the default MIDI device.
+  *
+  * <p>This method is equivalent to calling 
+  * <code>getSequencer(true)</code>.
   *
   * <p>If the system property
   * <code>javax.sound.midi.Sequencer</code>
   * is defined or it is defined in the file "sound.properties",
   * it is used to identify the default sequencer.
   * For details, refer to the {@link MidiSystem class description}.
   *
!  * @return the default sequencer, connected to a default Receiver
   * @throws MidiUnavailableException if the sequencer is not
   * available due to resource restrictions
+  * @see #getSequencer(boolean)
+  * @see #getSynthesizer
+  * @see #getReceiver
   */
  public static Sequencer getSequencer() throws MidiUnavailableException

2) Since now the new Sequencer would be useless, because trying to connect it to another Receiver would create a lot of confusion, add a method that explicitely returns a non-connected Sequencer:

  /**
   * Obtains the default sequencer, optionally connected to a 
   * default device.
   * If <code>connected</code> is true, the returned sequencer is 
   * connected to the default Synthesizer. If there is no Synthesizer
   * available, or the default Synthesizer cannot be opened,
   * the Sequencer is connected to the default Receiver.
   * The connection is made by retrieving a Transmitter instance 
   * from the Sequencer and setting its Receiver.
   * Closing and re-opening the sequencer will restore the 
   * connection to the default MIDI device.
   *
   * <p>If <code>connected</code> is false, the returned sequencer is 
   * not connected, it has no open Transmitters. In order to
   * play the sequencer on a MIDI device, or a Synthesizer,
   * it is necessary to get a transmitter and set its receiver.
   *
   * <p>If the system property
   * <code>javax.sound.midi.Sequencer</code>
   * is defined or it is defined in the file "sound.properties",
   * it is used to identify the default sequencer.
   * For details, refer to the {@link MidiSystem class description}.
   *
   * @return the default sequencer
   * @throws MidiUnavailableException if the sequencer is not
   * available due to resource restrictions
   * @see #getSynthesizer
   * @see #getReceiver
   * @since 1.5
   */
  public static Sequencer getSequencer(boolean connected) 
      throws MidiUnavailableException

======================================================================

###@###.### 2003-10-22

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b26 tiger-beta
2004-06-14

PUBLIC COMMENTS Clarify default connections in default sequencer
2004-06-10

EVALUATION ###@###.### 2003-10-02 Important to get into tiger. There are 2 "Plan B"'s: Plan B1) remove new sequencer Plan B2) only establish compatibility with old sequencer by always maintaining the default connection. This would mean that the API is wrongly implemented, and the reasons why we needed a new sequencer not fulfilled. Therefore, both Plan B's are highly undesirable. ###@###.### 2003-10-12 CCC approval requested.
2003-10-12