WO1998012876A1 - Procedes et appareil de codage et de decryptage des fichiers - Google Patents

Procedes et appareil de codage et de decryptage des fichiers Download PDF

Info

Publication number
WO1998012876A1
WO1998012876A1 PCT/US1997/016790 US9716790W WO9812876A1 WO 1998012876 A1 WO1998012876 A1 WO 1998012876A1 US 9716790 W US9716790 W US 9716790W WO 9812876 A1 WO9812876 A1 WO 9812876A1
Authority
WO
WIPO (PCT)
Prior art keywords
track
midi
synthesizer
given
stream
Prior art date
Application number
PCT/US1997/016790
Other languages
English (en)
Inventor
William A. Moline
Frederick A. Putnam
Original Assignee
Laboratory Technologies Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/716,949 external-priority patent/US6317123B1/en
Priority claimed from US08/732,949 external-priority patent/US5819108A/en
Priority claimed from US08/811,976 external-priority patent/US5883957A/en
Application filed by Laboratory Technologies Corporation filed Critical Laboratory Technologies Corporation
Publication of WO1998012876A1 publication Critical patent/WO1998012876A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04K—SECRET COMMUNICATION; JAMMING OF COMMUNICATION
    • H04K1/00—Secret communication

Definitions

  • the invention relates generally to encryption and decryption of information and more particularly to the encryption and decryption of MIDI files and tracks distributed via a public network such as the Internet.
  • the Musical Instrument Digital Interface is a standard protocol which was originally developed to permit electronic instruments such as synthesizers to communicate with each other.
  • One common use of the protocol is permitting a musician to play more than one electronic instrument at once.
  • the instrument that the musician is actually playing not only generates sounds, but also generates a sequence of event messages.
  • An event message may for example be a note on message, that indicates that a note of a given pitch has started to sound or a note off message that indicates that the note has ceased sounding. Many other kinds of event messages are defined as well.
  • Another instrument receives the event messages from the first instrument and responds by performing the actions indicated in the messages.
  • the event messages can be divided into two classes: the note on and note off messages and the remaining messages, which will be termed herein control messages.
  • MIDI devices include electronic musical instruments and the sound boards of many computers.
  • time relationships between events are simply determined by when the events appear in the event stream. For example, if a note is to be held for a period of one second, the note on message for the note will appear in the MIDI stream one second before the note off message for the note appears in the stream. Since the MIDI device will start sounding the note in response to the note on message and stop sounding the note in response to the note off message, the note will be sounded for one second.
  • the MIDI device may be assigned one or more channels. Each channel is represented by a channel number and each event message includes a channel number. A given MIDI device will respond to a given event message only if the channel number in the event message specifies one of the channels assigned to the MIDI device.
  • Each MIDI device has three connectors for the cables used to carry MIDI streams.
  • One of the connectors is an output connector.
  • the cable connected to it carries a MIDI stream of event messages that originate at the MIDI device; another of the connectors is an input connector; the connected cable carries a MIDI stream of event messages that the MIDI device will respond to if the event messages specify the channel currently assigned to the MIDI device
  • the third connector is a through connector; the connected cable carries the MIDI stream received in the input connector.
  • FIG 5 shows one such configuration 501.
  • Each MIDI device 113 has the three connectors: Input 505, output 507, and through 509.
  • Output 507(a) of MIDI device 113(a) is connected by MIDI cable 510 to input 505(b) of MIDI device 113(b), while through connector 509(b) is connected to input 505(c) of MIDI device 113(c).
  • the output of MIDI device 113(a) is played on both MIDI devices 113(b) and 113(c), additionally, notes produced by players of devices 113(b) and (c) will be heard from those devices.
  • MIDI sequencer 511 receives one or more MIDI streams 111 and makes MIDI tracks 105 out of the MIDI streams 111 and MIDI files 103 out of the MIDI tracks
  • the files and tracks are stored in storage devices such as standard memories and/or disk drives
  • MIDI file 103 has a header 104 which contains information such as the number of tracks
  • the MIDI file also contains at least one track 105
  • a given track / in such a file is indicated hereinafter by 105(i)
  • Each track 105(i) contains a sequence of events 106
  • Each event 106(j) has two parts an event message 117 and an elapsed time descriptor 1 19.
  • the elapsed time descriptor indicates the time that is to elapse between the preceding event 106(j-l) and event 106(j).
  • a given event 106's position in file 103 may be indicated by the index of its track and its own index in the track. Event 106(ij) is thus eventy in track /.
  • the MIDI stream 111 is generated from MIDI file 103 by MIDI controller 107.
  • Prior-art MIDI controller 107 does this by first writing all of the tracks 105 from file 103 into controller memory 109, as shown by arrow 108, and then reading all of the tracks simultaneously in the fashion just described, as shown by arrow 110.
  • MIDI controller 107 maintains a song position time value 121 which the controller can use together with the elapsed time descriptors to determine which event messages are to be output from the tracks at a given time.
  • MIDI stream 111 generally consists of interleaved event messages 117 from the tracks 105.
  • MIDI stream 111 may then be responded to by any MIDI device 113, which then drives loudspeaker 115 to produce the sounds specified by MIDI stream 111.
  • the standards for both MIDI streams and MIDI files are defined in the MIDI Specification, copyright 1983 and available from the MIDI Manufacturers' Association.
  • MIDI tracks and MIDI streams represent commands to MIDI devices, and not the output of those devices, and are consequently much smaller than representations of the output of the devices. This property is particularly valuable where storage space is limited, for instance in low-cost electronic devices, or where a low-bandwidth medium such as the Internet is being used to transmit the representation.
  • FIG. 1 shows a prior-art technique for distributing music over the Internet An important limitation of the Internet is that it is not a real-time medium.
  • MIDI files 105 This problem was overcome in the prior art by distributing music for MIDI devices over the Internet as MIDI files 105 using the techniques shown in FIG. 1.
  • a MIDI file 103 was made from the MIDI stream 111, then the MIDI file was distributed over the Internet, and the arrangement shown at 101 of FIG. 1 was used to play the file on a MIDI device 113.
  • the parent and the grandparent of the present patent application both concerned improved techniques for overcoming the non-real-time characteristics of the Internet and thereby making it possible to begin hearing a MIDI file without delay and to hear MIDI music as it was produced.
  • FIG. 12 The present patent application deals with the problem of protecting MIDI tracks and files from unauthorized copying. Copying is generally a more severe problem in the digital realm than in the analog realm because a copy of a digital representation is as good for all purposes as the original digital representation. In the case of MIDI tracks and files, copying is made even more attractive by the smallness of the MIDI representation and by the fact that it can be played on any kind of MIDI device.
  • FIG. 12 shows a system 1201 in which such techniques are applied to a MIDI file 103 which is being sent by a network 1211 from a source 1203 to a destination 1213.
  • MIDI file 103 is provided to encrypter 1207, which uses one of many known techniques to produce an encrypted version of MIDI file 1209 which has been encrypted using an encryption key 1208.
  • the file may only be decrypted by someone who has a decryption key for the file.
  • Encrypted file 1209 is then sent via network 121 1 to destination 1209, where it is decrypted by decrypter 1217 using the decryption key 1218 appropriate to the encryption made by encrypter 1207.
  • Decrypted MIDI file 1219 is identical to original MIDI file 103 and can be read by a file to stream translator 1221 to produce a MIDI stream 111 in the fashion described above.
  • MIDI stream 111 is then sent to MIDI device 113, which produces analog signals 1227 that then go to loud speaker 115.
  • FIG. 12 From the point of view of preventing copying of MIDI tracks and files, the arrangement of FIG. 12 has a number of problems. What the publisher of the MIDI track or file wishes the user to get in unencrypted form is only the sound produced when the MIDI device plays the MIDI stream. Even giving the user access to MIDI stream 111 is unacceptable, since anyone who has a MIDI sequencer 511 can produce a MIDI file 103 from the MIDI stream 111, and
  • MIDI sequencers 511 can easily be implemented in software that will run on a standard personal computer (PC).
  • system 1201 the user has access to decrypted MIDI at many points. Most obviously, system 1201 produces decrypted MIDI file 1219, which is accessible to the user of system
  • the DLL When a program executing in a personal computer uses programs in a dynamically-linked library, the DLL is linked to the program that uses it as the latter program begins executing. It is consequently easy for the user to substitute his own DLL for either the file to stream translator or the MIDI device 113 for the ones intended to be used to play the MIDI file, and instead of playing the MIDI file, the user can simply output the events 1220 to a file of his own or output MIDI stream 111 to a sequencer 511.
  • FIG. 1 is a block diagram of a prior-art system for playing a MIDI file
  • FIG. 2 is a block diagram of modifications to a MIDI controller to permit playing an incomplete track
  • FIG.3 is a block diagram of a further modification to a MIDI controller to permit playing a multi-tracked MIDI file with an incomplete track
  • FIG. 4 is a block diagram of an embodiment of the invention for use with a World Wide Web browser
  • FIG. 5 is a prior-art configuration of MIDI devices
  • FIG. 6 is an overview of a technique for transmitting a live performance on a MIDI device via the Internet
  • FIG. 7 is a detail of a technique for distributing a MIDI track over the Internet as the track is created;
  • FIG. 8 is a detail of a technique for reading the track as it is received
  • FIG. 9 is an overview of techniques which permit players of MIDI devices to collaborate using the Internet
  • FIG. 10 is a detail of buffer 704 in a version of the system of FIG. 9 which makes it possible for users of the Internet to participate in jam sessions;
  • FIG. 11 is a detail of stored track 805 with an improvement which makes it possible to distribute an endless MIDI track.
  • FIG. 12 shows a prior-art technique for encrypting and decrypting MIDI files;
  • FIG. 13 shows a technique for encrypting and decrypting MIDI files which does not give a user access to a decrypted MIDI file, track, or scheme;
  • FIG. 14 shows encryption in a preferred embodiment
  • FIG. 15 shows decryption in a preferred embodiment.
  • the reference numbers in the drawings have at least three digits.
  • the two rightmost digits are reference numbers within a figure; the digits to the left of those digits are the number of the figure in which the item identified by the reference number first appears. For example, an item with reference number 203 first appears in FIG. 2.
  • the Detailed Description of the grandparent first describes how MIDI controller 107 may be modified to begin playing a track before the entire track has been received in MIDI controller 107, then describes how MIDI controller 107 may be modified to play a Format 1 MIDI file when all of the MIDI file's tracks have not yet been loaded into controller 107's memory, and finally shows how the invention may be implemented in the environment provided by the Netscape Web browser.
  • the Detailed Description of the parent shows how MIDI tracks that are transmitted over a network may be played as they are produced and how a system which permits MIDI tracks to be played in this fashion can be further modified to permit the playing of endless MIDI tracks or to provide various modes of "playing along" as the track is produced.
  • FIG. 2 Playing a Track while it is being Received: FIG. 2
  • Fig. 2 shows how a MIDI controller like that shown at 107 may be modified to begin playing a track of a MIDI file 103 before the entire track has been received in controller 107
  • Modified controller 201 has two main components: a MIDI file reader 205, which reads the track 203 being received and places information from the track in memory 109, and MIDI stream generator 219, which reads what file reader 205 has placed in memory 109.
  • MIDI stream generator 219 does not wait to begin reading until file reader 205 has finished reading all of track 203 into memory 109, but instead operates concurrently with file reader 205.
  • both file reader 205 and MIDI stream generator 219 are event driven: File reader 205 responds to an event that indicates that the next portion of track 203 has been received in controller 107; whenever the event occurs, file reader 205 runs and places the MIDI events 106 from that portion in memory 109; MIDI stream generator 219 responds to a timer runout event. That event occurs whenever a timer set by MIDI stream generator 219 runs out. In a preferred embodiment, MIDI stream generator 219 sets the timer to run out after an interval of 2 milliseconds. In general, the shorter the interval, the closer the output stream will approximate the original MIDI stream captured in the MIDI file.
  • MIDI stream generator 219 keeps track of the last event 106 that it output, the amount of time that has actually elapsed since it began playing the track, and the total amount of time specified by the elapsed time indicators in the events 106 played thus far. Each time the timer expires, MIDI stream generator 219 looks at events 106, beginning with the one following the last event 106 that it output. If the sum of the total elapsed time and the elapsed time indicator for an event is less than or equal to the time that has actually elapsed, MIDI stream generator 219 outputs the event.
  • intervals at which the timer runs out are short enough so that the intervals separating the event messages in MIDI stream 111 are substantially those specified in the elapsed time descriptors 119. Since file reader 205 generally receives track 203 much more rapidly than MIDI stream generator 219 reads it, MIDI stream generator 219 can play track 203 as it is loaded.
  • MIDI file reader 205 includes two subcomponents that are important for the present discussion: parser 207 and time converter 209.
  • Parser 207 reads events 106 in order from track 203.
  • Each event 106 of course includes event message 117 and elapsed time descriptor 119.
  • time converter 209 converts elapsed time descriptor 119 to time stamp 211.
  • elapsed time descriptor 119 specifies the time elapsed since the last event message 117; time stamp 211 contains the sum of the elapsed times in all of the time descriptors 119 from the beginning of track 203 to the current event 106.
  • Elapsed time descriptor 119 is converted to time stamp 211 in the preferred embodiment in order to simplify the computations performed by MIDI stream generator 219 in determining whether an event is to be output to MIDI stream 111.
  • stored track 215 is subdivided into elements 221.
  • MIDI file reader 205 begins reading events 106 from file 203, it allocates an element 221; it places events 106 in the element until it is full and then allocates another element. All elements but the last to be allocated are full, and consequently, MIDI stream generator 219 can detect when it is approaching the end of stored track 215 currently being -written by the presence of an incomplete element 223.
  • an incomplete element 223 is one for which write pointer 225 is not at the end of the element.
  • MIDI stream generator 219 generates MIDI stream 111 from stored track 215 as follows:
  • MIDI stream generator 219 plays each track at the position determined by SongPos 217 and must therefore be able to begin playing tracks other than the first track to be received "in the middle".
  • Starting in the middle is complicated by the fact that how a MIDI device responds to a note on or note off event message is determined not only by the message, but also by control event messages which preceded the note on or note off message in MIDI stream 111.
  • FIG. 3 shows how file reader 205 writes the tracks it receives into memory 109 and how MIDI stream generator 219 reads the tracks.
  • File reader 205 receives the tracks sequentially, and as it receives each track, it writes the track to memory 109 as described with regard to
  • FIG. 2 above.
  • File reader 205 has already read tracks 105(1) through 105(n-l) into memory as stored tracks 301(1) through 303(n-l). That these tracks are complete is indicated by the fact that the track's write pointer 225 is at the end of the last element.
  • File reader 205 is presently reading track 105(n) and has stored the portion it has read in incomplete stored track 304.
  • Each track 303 is made up of a sequence of elements 221, with the last element in track 304 being an incomplete element 223 to which file reader 205 is still writing events 213.
  • MIDI stream generator 219 begins generating MIDI stream 111 from track 303(1) as soon as file reader 205 has written the first complete element 221 to the file. In other embodiments, MIDI stream generator 219 may begin reading even before the first complete element has been written.
  • MIDI stream 111 contains only event messages from track 303(1), and consequently, the MIDI device that is responding to stream 11 1 plays only the part contained in track 303(1). For example, if that track contains the percussion part, that is the first part that the responding device plays.
  • file reader the file reader
  • MIDI stream generator 219 begins generating MIDI stream 111 from track 303(2) as well, and so on, until file reader 205 has written the last track past the location currently represented by SongPos 217. At that point, MIDI stream 1 11 is being generated from all of the tracks 303 and 304.
  • the music begins with the part contained in the first track to be received; as each track is received, the part contained in the track is added, until the listener finally hears all of the parts together.
  • This incremental addition of parts has an effect which is similar to the incremental increase in definition that is often employed when a graphics element is displayed on a Web page.
  • the user begins seeing the graphics element or hearing the music with minimum delay and can often even decide on the basis of the low-definition display of the graphics element or the rendering of the music with fewer than all of the parts whether he or she has any further interest in the graphics element or the music.
  • MIDI stream generator 219 generates MIDI stream 111 from complete tracks 303 (1..n) and incomplete track 304 as follows:
  • MIDI stream generator 219 may search back through the track until it has found all of the control event messages relevant to the current position of SongPos 217 and then output only those control event messages before beginning to output note on or note off event messages.
  • FIG. 4 Incorporating the Invention into a Web Page Browser: FIG. 4
  • MIDI file is being transferred via the Internet, either as an inclusion in a Web page which has been downloaded by a user or as a file that is referred to by a link in a Web page.
  • the most natural place to implement the invention is in a World Wide Web browser.
  • FIG 4 shows a presently-preferred implementation of the invention in a Netscape browser System 401 includes a World Wide Web server 403 which serves pages 405 written in the HTML language via Internet 411 to a World Wide Window client 413
  • An HTML page 405 may include a link 407 to a MIDI file 409
  • Client 413 may be implemented in any kind of computer system, but client 413 is implemented in FIG 4 in a standard PC
  • the PC has a memory 419, a processor 415 which includes a sound card 417 which is a MIDI device, and peripheral devices including a CRT display 421, a loudspeaker 423 which is connected to sound card 417, keyboard 425, and mouse 427
  • the program which causes the PC to function as a World Wide Web client 413 is Netscape browser 429, which responds to an input of a Universal Resource Locator (URL) specifying an HTML page 405 in a particular server 403 by first executing a protocol which retrieves the page 405 from server 403 and then interprets
  • a given HTML page may have non-HTML inclusions such as pages written in different mark up languages, files containing vector graphics, compressed video, sound files, or MIDI files If a browser includes the software to respond to such a file, the browser will display or play the file, otherwise, it will just display the surrounding HTML Given the pace at which Web technology is changing and the varying needs of users of browsers, providing the software needed to read inclusions has become a problem for manufacturers of browsers Netscape
  • a MIDI plugin incorporating the invention is shown at 431 in FIG 4
  • a user of a Netscape browser 429 can use his browser to download a desired plugin from the Internet, and after the browser has downloaded the plugin, the user can place it in a directory in which browser 429 looks for plugins
  • browser 429 receives an inclusion of the type read by the plugin, the browser activates the plugin
  • the plugin uses browser 429's facilities to fetch the inclusion and then reads or plays the inclusion.
  • a MIDI plugin 431 which incorporates the invention performs substantially the same tasks as a MIDI controller which incorporates the invention.
  • Plugin 431 has a file reader 205 and a MIDI stream generator 219.
  • File reader 205 reads MIDI file 409 serially as it is received in browser 429 and outputs events 213 to memory 419.
  • File reader 205 includes a parser 207 which reads events 106 and a time converter 209 which converts elapsed time descriptors 119 to time stamps 211 and thereby produces events 213.
  • MIDI stream generator 219 operates as just described to generate MIDI stream 111 from tracks 303 and 304.
  • the event messages go to sound card 417, which drives PC loudspeaker 423.
  • API Application Programmer's Interface
  • live MIDI is the distribution of a MIDI track from a server to one or more clients using a non-real-time protocol and the playing of the MIDI track by the clients as the track is being distributed.
  • live MIDI is to "broadcast" recitals given on MIDI devices as they occur. In this use, the MIDI stream produced during the recital is transformed into a MIDI track as it is being produced and the MIDI track is distributed to the clients, again as it is produced, so that the clients are able to play the MIDI track as the MIDI stream is produced during the recital.
  • the techniques used to implement live MIDI are related to techniques disclosed in the parent of the present patent application for reading a MIDI track 105 as it is received.
  • These techniques, and related techniques for generating a MIDI track from a MIDI stream as the MIDI stream is received in a MIDI sequencer are employed to receive the MIDI stream, produce a MIDI track from it, distribute the track using the non-real-time protocol, and play the track as it is received to produce a MIDI stream.
  • the varying delays characteristic of transmissions employing non real-time protocols are dealt with by waiting to begin playing the track in the client until enough of the track has been received that the time required to play the received track will be longer than the greatest delay anticipated in the transmission..
  • Other aspects of the techniques permit a listener to begin listening to the track at points other than the beginning of the track, permit the distribution of an essentially endless track, and permit use of the non-real-time protocol for real-time collaboration among musicians playing MIDI devices.
  • FIG. 6 shows a system 601 that embodies the principles of the invention.
  • FIG. 6 has three main components: one or more senders 621 (l..m) which are sources of MIDI streams 111, Internet sites 610(a and b) that are connected via Internet 608 to senders 621, and one or more receivers 619(l..n), which have established connections with Internet sites 610 to receive a MIDI track 607 made from MIDI stream 111 and produce a MIDI stream 111 from track 607.
  • senders 621 l..m
  • Internet sites 610(a and b) that are connected via Internet 608 to senders 621
  • receivers 619(l..n) which have established connections with Internet sites 610 to receive a MIDI track 607 made from MIDI stream 111 and produce a MIDI stream 111 from track 607.
  • senders 621 two kinds of such senders are shown.
  • Components 113 and 605 are identical for both.
  • a MIDI device 113 produces a MIDI stream 111 and provides it to a MIDI track generator 605.
  • MIDI track generator 605 generates a MIDI track 607 from MIDI stream 111.
  • MIDI track 607 is like MIDI track 215 of the parent patent application in that track 607 is a sequence of events 213.
  • Each event 213 contains a MIDI event message 117 and a time stamp 211 which indicates the length of time between the beginning of the MIDI stream being recorded in the track and the occurrence of the event message 117 contained in the event.
  • the difference between sender 613 and sender 625 lies in their relationship to Internet 608.
  • Sender 623 has access to Internet 608 but is not itself a site 610 in Internet 608, that is, other participants in Internet 608 cannot use an Internet browser to establish a connection with Sender 623.
  • Sender 625 is itself a site 610(a) in Internet 608.
  • Beginning with sender 613 since sender 613 is not itself a site in Internet 608, it must send track 607 to such a site, in this case, site 610(b). It does so by sending track 607 to Internet interface 606, which has established a TCP session with Internet site 610(a) and outputs track 607 as a sequence of packets 604 addressed to Internet site 610(a). The packets satisfy the IP protocol.
  • the TCP session cannot guarantee that Internet site 610 will receive a given packet at any given time or indeed receive it at all, or that it will receive a given sequence of packets in any particular order, but it can guarantee that Internet site 610 and sender 621 can detect lost or damaged packets and can also request that a lost or damaged packet be resent.
  • the protocols thus provide an environment in which all packets sent via a given session eventually arrive.
  • Receivers 619 who wish to hear the stream 111 produced by sender 623 establish a connection via Internet 608 with Internet site 610(b).
  • Internet site 610(b) receives packets 604, it reads the data from them to produce a copy of MIDI track 607 in Internet site 610(b). It then provides the events in the copy of MIDI track 607 in the order in which they occur in the track to each of receivers 619. It does so via the Internet, and consequently, the events must be incorporated into packets destined to the various receivers 61 .
  • a receiver 619 may begin receiving track 607 from Internet site 610 at any time after Internet site 610 has itself begun to receive it.
  • sender 625 that sender itself includes Internet site 610(a), so that receivers 619 are able to establish a connection via Internet 608 directly with sender 625.
  • sender 625 that sender itself includes Internet site 610(a), so that receivers 619 are able to establish a connection via Internet 608 directly with sender 625.
  • Internet interface 606 is between site 610(a) and the remainder of the Internet. Which of the arrangements of senders 621 is to be preferred is determined by circumstances; where there are relatively few receivers 61 , the resources available in a Web site belonging to a sender 621 may be sufficient to serve them all; where there are many receivers 619, a powerful Internet site owned by a party such as a publisher for MIDI music may be required
  • Each receiver 619 includes an Internet interface 606 for receiving IP packets 604 according to the TCP protocol and outputting track 607, a track-stream transformer 612 for transforming track 607 back into a MIDI stream 111, and a MIDI device 113 which can respond to stream 111.
  • Track stream transformer 612 works generally in the same fashion as apparatus 201 of the parent application.
  • Track 607 received at receiver 619 is identical to track 607 generated by MIDI track generator 605, but is received in receiver 619 with a delay which is dependent upon the path(s) in Internet 608 by which the packets 604 carrying track 607 are sent to receiver 619 and upon the condition of the Internet nodes and links on those paths. The delay will generally be different for each receiver 619. This fact is indicated in FIG.
  • a receiver may be implemented as software executing on a processor.
  • the processor may be in a PC, or may be in a specialized audio device.
  • the software may be an independent module or it may be implemented as part of an Internet browser. In the latter case, it is particularly advantageous to implement the software as a plugin for the browser.
  • the amount of track 607 that must be accumulated before receiver 619 begins playing the track is determined by a delay parameter set by the user of receiver 619(1); in other embodiments, Internet site 610 may use information that it has about the behavior of Internet 608 to provide a delay parameter to receiver 619(1) when receiver 619(1) establishes the connection with Internet ate 610 over which track 607(1) is to be received. It should be pointed out here that the technique for dealing with transmission delay can also be used in playing MIDI tracks in the manner described in the parent of the present patent application.
  • MIDI track generator 605 is implemented using the portion of a MIDI sequencer which generates a MIDI file from MIDI stream 111. That portion has been modified in two respects: 1.
  • the MIDI track 607 generated by MIDI track generator 605 is not a standard MIDI track, 105 with elapsed time descriptors 119. Instead, it is a MIDI track like stored track 215 of the parent. In track 607, the elapsed time descriptors are replaced by time stamps 211.
  • Each time stamp indicates the time that has elapsed between the time the first event message in the track was received in MIDI track generator 605 and the time the current event message was received.
  • the time stamps thus give times relative to the beginning of the MIDI stream represented by track 607. 2. Instead of outputting track 607 to a file in the sequencer's memory as the track is created, it outputs track 607 to Internet interface 606 or to Internet site 610(a) as it is created.
  • Internet site 610(b) receives and transmits information via sockets 707 in Internet interface 604.
  • Each session with an entity to which or from which site 610 is receiving data has a socket 707.
  • a socket 707(a) for the session with sender 621 and sockets 707(1..n) for the receivers 619(1..n).
  • the socket receives IP packets 604 from MIDI track generator
  • track 605 and produces therefrom data which contains MIDI track 607.
  • the track data is stored in track buffer 704.
  • track 607 is made up of a sequence of event messages 117 and time stamps 211.
  • a write pointer 705 indicates the point at which data from socket 707 is currently being written to track 607.
  • Track 607 is read as it is written by track reader 705.
  • Track reader 705 maintains a read pointer 706 in track 607 for each receiver 619.
  • FIG. 7 thus shows read pointers 706(1.. n) Of course, a number of the read pointers may point to the same position in track 607.
  • track reader 705 As track reader 705 reads track 607 for a given receiver 619(i), it sends a portion of the track at the current position of read pointer 706(i) to socket 707(i) and updates pointer 706(i) to point to the next portion to be read for that client 619(i). If a read pointer 706(i) reaches the position of write pointer 708, track reader 705 simply stops sending portions of track 607 to receiver 619(i) until further portions of track 607 have been received in Internet site 610 and write pointer 708 has been updated accordingly.
  • Track-stream transformer 612 is a variation on apparatus 201 of the parent patent application.
  • Track reader 803 receives track 607(i) and parses it as it is received to obtain events 213; however, track 607(i) already contains time stamps 211, so there is no need to convert elapsed time stamps to time descriptors.
  • the events are written to track buffer 817 in memory 109 to form stored track 805.
  • the event currently being written is indicated by write pointer 809.
  • MIDI stream generator 811 reads stored track 805 as explained for MIDI stream generator 219. MIDI stream generator 811, however, delays beginning to read stored track 805 until enough of stored track has accumulated to require the delay period to play.
  • the delay period is implemented as follows: first a server start time is determined which is the system time at which receiver 619 creates the buffer in which stored track 805 is stored. The delay period is then added to the server start time to obtain a play start time. Beginning at the start of stored track 805, the time stamp of each event is added to the server start time and subtracted from the play start time. If the result is negative, the amount of stored track 805 from that event to the beginning of the track is not enough to fill out the delay period. If the result is 0 or positive, there is enough of stored track 805 to fill out the delay period and receiver 619 can start playing the track from the beginning.
  • MIDI track 607 requires so little space to represent music
  • the first sequence of events to be received in receiver 619 often contains enough events to fill out the delay period, and receiver 619 can begin playing stored track 805 immediately.
  • the portion of the code for MIDI stream generator 811 which executes this algorithm appears in FIG. 8 as delayer 81 .
  • the amount of delay is received as a delay specification parameter 815 in delayer 813.
  • the user of receiver 619(i) provides parameter 815; however, in other embodiments, it may be provided by Internet site 610 as described above or a combination of the techniques may be employed. For example, a default delay may be provided by Internet site 610 and the user may provide a delay parameter which overrides the default delay.
  • a receiver 619 When a receiver 619 is implemented in a system which does not have a real-time operating system, for example, a system which employs an operating system such as Windows 95, the operating system can introduce an element of delay in the operation of MIDI stream generator 811.
  • the delay occurs when the interval between reads of stored track 805 becomes longer than the 2 millisecond interval of the preferred embodiment.
  • This problem is dealt with in the preferred embodiment by means of a MAX JITTER parameter which specifies a maximum amount of time by which the time stamp 211 of an event 213 that specifies a note-on message may indicate a time that precedes the time represented by SongPos 217. If the time stamp of such an event exceeds MAX JITTER, the event is not output to MIDI stream 111, thereby effectively dropping the note from the stream.
  • Note off event messages and control event messages are, however, always output.
  • receiver 619 must receive all of the track 607 that Internet site 610 has received.
  • the reason for this is that the meaning of any given point in MIDI stream 111 is potentially determined by all of the control event messages and note off event messages which preceded that point in the stream.
  • a receiver 619(i) may begin listening in the middle of track 607(i), but when it does so, track-stream transformer 612 must go to the beginning of track 607(i) and output all of the control event messages from the beginning up to the point where the listening is to begin to MIDI stream 11 l(i). That in turn means that the buffer in which track 805 is stored must be large enough to store the entire track 607. The same is of course true for track buffer 704 in Internet site 610.
  • MIDI stream 111 is made up of note on and note off event messages.
  • This technique is thus a modification of the one used in the parent of the present patent application to start outputting a MIDI stream from the middle of a MIDI track.
  • Track 607 Another way of dealing with the difficulty which does not require that all of track 607 be stored in Internet site 607 is to make a separate control event buffer which contains only control event messages, but which can be made large enough to contain all of the control event messages from even the longest track 607.
  • Track 607 continues to contain both control event messages and on-off event messages as before, but since the control event buffer will contain all of the control event messages received thus far in track 607, it is no longer necessary for track buffer 704 to contain all of track 607 that has been thus far received.
  • track reader 705 When a new receiver 619 establishes a connection to Internet site 610, track reader 705 first outputs all of the event messages in the control event buffer to the new receiver and then begins outputting the entire track 607.
  • FIG. 11 A third solution to the problem is shown in FIG. 11.
  • This solution takes advantage of the fact that the only event messages that are really required to start reading track 607 in the middle are controller event messages. These messages specify settings of control devices on the MIDI devices which respond to the messages. Which MIDI devices respond is of course determined by the channel specified in the message. All of the controller event messages contain three bytes. The first byte specifies a channel number and a controller event message type, the second specifies the number of the controller, and the third specifies the setting of the controller. As can be seen from this, a given channel can have a maximum of 128 controllers, and the settings for a given controller can range from 0-127. The settings are furthermore absolute, and not relative to an earlier setting of the controller.
  • the given point is specified by the value in time stamp 211 of the event 213 at that point in the track.
  • One way of establishing the controller state of a given point in a track 607 is to simply transmit all of the control event messages from the beginning of track 607 up to the given point. Another way is shown in FIG. 11.
  • the controller state of a given controller state point 1113 in a given portion 1103 of track 607 is represented by means of a set of controller state buffers 1 102 corresponding to the controller state point 1113.
  • Each buffer 1105(i) has 128 entries, one for each possible controller for the channel, and the entry for a given controller contains the setting for the controller at control state point 1113.
  • Track reader 705 Given the controller state for a given controller state point 1113, Track reader 705 is able to generate the corresponding controller event messages and output them to MIDI stream 111
  • Track reader 705 can thus start reading track 805 at any point following a controller state point 1113. To start reading, Track reader 705 backs up to controller state point 1113, generates the controller event messages from the channel controller buffers 1102 for controller state point 1113, then outputs only control event messages up to the point at which reading is to begin, and at that point begins outputting all of the event messages in track portion 1103.
  • the controller state buffers could of course also be sent to track-stream transformer 612 in receiver 619 when the connection with Internet site 610 is established and the controller event messages generated there. It seems more reasonable, though, to keep transformer 612 a simple reader of tracks and implement more complicated functions in
  • Channel controller buffers 1102 must of course be kept current. One way to do this is to update buffers 1102 each time a new controller event message comes in and at the same time update controller state point 1113 to contain the timestamp for the latest controller event message. Another way to do it is to begin building a new set of channel control buffers 1102 at the point following the controller state point 1113 for the set of buffers 1102 currently being used and periodically merge the contents of the old and new buffers. Again, controller state point 1113 would be updated to reflect the position of the controller state buffers that are currently in use. In any case, the first set of channel controller buffers 1102 is of course set from the controller event messages that are sent prior to the beginning of a song.
  • MIDI track 607 may be endless. In such an endless track 607, it will be at most necessary to occasionally reset a timestamp value to 0 and recompute following timestamp values relative to the reset value.
  • One use of such an endless MIDI track 607 is to provide background music; another use is to provide a site in the Internet at which musicians can come and go as participants in an endless jam session. This latter possibility will be explored in more detail below.
  • the techniques involved in live MIDI can also be used for participatory music making. If the MIDI device 113 in receiver 619 is a MIDI electronic instrument and the MIDI stream is output to the device's input connector, the electronic instrument will interpret the stream, while it is doing that, the user may use another input to the electronic instrument to play along.
  • the arrangement would have the same effect as far as the MIDI stream is concerned as the connection between MIDI device 113(a) and 113(b) in FIG. 5.
  • variation would be to additionally connect another MIDI device 113 to the first one by connecting the thru connector of the first device to the in connector of the other device, as is shown in the connection between device 113(b) and 113(c) in FIG. 5. This could be used where it is desired to play the stream on different types of MIDI instruments. Of course, people could play along on either instrument.
  • a refinement of playing along is the following: if a channel is assigned to each of the electronic instruments in an ensemble piece, Internet site 610 can indicate to a user who wishes to play along what channels correspond to what instruments, and a player of a given kind of instrument can provide a parameter to track-stream transformer 612 which indicates that track-stream transformer 612 is not to output event messages for that instrument's channel to MIDI stream 111. The player can then play along with the MIDI stream produced from the remaining channels.
  • the channel parameter could be provided to Internet site 610, which would then remove such events for the channel from track 607 sent to receiver 619 that provided the channel parameter. It should be noted here that this technique can also be employed when a MIDI device is being played from a MIDI file
  • FIG. 9 A system 901 which permits collaboration across the Internet is shown in FIG. 9.
  • a number of participants 905 have connections via Internet 608 with Internet site 903.
  • Each participant 905 not only has a track-stream transformer 612, but also a MIDI track generator 605, and consequently can not only receive a MIDI track from Internet site 903, but can also provide a MIDI track to Internet site 903
  • Internet site 903 has further been modified not only to provide MIDI tracks to participants 905, but also to receive MIDI tracks from the participants and provide them to the participants 905 or to other entities connected to Internet site 903.
  • One such entity, archiver 904 is shown in FIG. 9.
  • Archiver 904 stores MIDI files 905 and includes a file reader 902 which reads MIDI file 905 to produce MIDI track 607 and a file writer 906 which reads a MIDI track 607 to produce a MIDI file 905. Since the difference between the MIDI tracks 607 employed in the preferred embodiment and the MIDI tracks 105 employed in standard MIDI files is simply the use of time stamp 211 instead of elapsed time descriptor 119, the transformations performed by reader 902 and writer 906 will pose no problems to those skilled in the art. As will be described in the following, system 901 with archiver 904 and one or more participants 905 can be used to produce music in the same fashion as is done in a modern recording studio.
  • a session may proceed as follows: first a click track is made which sets the tempos for the song. Then the drummer comes in and follows the click track to produce a percussion track; thereupon, the bass player comes and produces his track as he listens to the percussion track. Then the lead vocalists or instrumentalists come and produce their tracks as they listen to the tracks that have already been made. Finally, the background vocalists and instrumentalists produce their tracks as they listen to the previously-made tracks. Once the whole song has been recorded in this fashion, individual participants may redo their tracks so that they better fit the whole.
  • MIDI music can be produced using system 901 in exactly the same fashion.
  • system 901 When system 901 is so used, the MIDI device in a participant 905(i) has its own channel.
  • the simplest way of using system 901 is to permit the players to modify a previously-made MIDI track stored in a file in archiver 904.
  • the player can request that Internet site 903 establish a connection with archiver 904 and begin receiving track 607 made from the file.
  • Internet site 903 then provides the track in the manner previously described to track-stream transformer 612, which then provides the MIDI stream represented by the track to MIDI device 13(i).
  • the performer may simply want to hear the present state of things
  • the performer When the performer is ready to begin working on his or her part of the performance, he or she requests Internet site 903 to again provide the track, but this time provides a channel parameter to transformer 612 that operates in the manner described above with regard to playing along to inhibit track-stream transformer 612 from outputting event messages for the channel.
  • the performer begins playing his or her part, and his MIDI device 113(i) outputs a MIDI stream 904(i) of event messages on the MIDI device's channel.
  • Stream 904(i) may be simply event messages for the MIDI device's channel, or the MIDI device 13 may also provide all of the event messages that it received in stream 11 l(i). In the latter case, MIDI stream 904(i) is effectively the original performance with a new version of the player's channel.
  • MIDI track generator 605 then makes the stream into a track 906(i) with time stamps 21 1 relative to the beginning of the song, Internet interface 606 sends track 906 as a sequence of packets 907, and Internet site 903 delivers the packets to archiver 904, where a new version of MIDI file 905 is created.
  • file writer 906 can easily integrate the new channel into MIDI file 905 by having file reader 902 read MIDI file 905, removing the event messages for the channel as it does so, and providing the modified track 607' to file writer 906.
  • File writer 906 then simply incorporates the track 906(i) with the new version of the channel into track 607' to produce track 607" . The incorporation is easily done, since the time stamps in track 906(i) indicate where the event messages for the channel are to go in track 607".
  • the player can repeat the foregoing process as many times as necessary, and the same can be done by each player in the group.
  • An important advantage of working in the manner described above is that it ensures that all of the players are working on the same copy of MIDI file 905. Indeed, all of the techniques employed to ensure consistency of a document produced by a group can be used in system 901. System 901 can be used for collaboration even where there is no preexisting MIDI file 905 to be worked on. This can be done as follows: all of the musicians have established connections with Internet ate 903. Then one musician, perhaps the drummer, begins playing, to produce MIDI stream 904(1), which goes to Internet site 903 and is immediately sent to the participant systems 905 for the other performers.
  • MIDI tracks 906 (2..n) to Internet site 903, which provides the tracks to archiver 904.
  • Archiver 904 combines the tracks in a MIDI file 905, and that file can be then worked on in the manner just described.
  • chat session In which people can send messages to a site in the Internet and receive all of the messages that arrive at the site as they arrive.
  • the result is the equivalent of a conversation among a group of people, except that written messages replace spoken words.
  • an Internet chat session can go on forever, with participants coming and going as they like.
  • the musical equivalent of a conversation is a jam session.
  • System 901 makes it possible to have an Internet jam session that is the musical equivalent of an Internet chat session.
  • the Internet jam session is rendered possible by the fact that there is an underlying repetitive structure in most jam sessions which defines the rhythm and harmony. Everything the participants do fits this underlying structure, and consequently, something that a participant plays in one repetition will generally make sense in a later repetition as well.
  • Internet site 903 in system 901 When Internet site 903 in system 901 is supporting an Internet jam session, it continually provides at least a track that represents the repetitive pattern as track 607.
  • the track 607(i) that he receives is made up of event messages from the repetitive pattern, and if there are currently participants in the jam session, event messages from tracks output from other participants 905.
  • Each track from a participant 905 is synchronized with the repetitive pattern.
  • the tracks from which track 607(i) is currently being produced is made up of tracks from participants 905 that were produced at different times.
  • each track works with the repetitive pattern, the tracks will generally also work with each other
  • the tracks from which the jam session output is produced may contain event messages for a channel that represents a given instrument. If the user of participant 905 plays that instrument, he or she can indicate that fact to participant 905 and Internet site 903
  • Participant 905 will then not output event messages for that channel to MIDI stream 11 l(i)
  • FIG. 10 shows the synchronization technique described above in more detail.
  • a track buffer 1009 in Internet site 903 contains the tracks from which the track 607(i) sent to participant 905(i) is produced.
  • the tracks include a track 102 with a repetitive pattern 1003 which has a repetition time 1007 and may include tracks 1005( 1..n) from other participants 905 Tracks 1005(l..n) are synchronized with repetition pattern 1003.
  • a simple way to do this is to reset the value used in the time stamps to 0 at the beginning of each repetition pattern in track 1002 and to set up each participant 905 to do the same with the track 1005 it produces
  • a given participant 905(i) receives track 607(i) which has been produced in the manner just described. Participant 905(i) suppresses the event messages for the channel upon which participant 905(i) is going to provide output, and then begins providing track 1005(i), with time stamps that are synchronized with the periods of the time stamps of track 607(i) Track 105(i) contains repetition sequences 1008, each of which fits repetitive pattern 1003 When
  • Internet site 903 begins receiving track 1005(i), it synchronizes the repetitive sequences 1008 8 in 1005(i) with repetitions 1003 and outputs the track as part of output 607 to other participants
  • a participant 905 may join or leave the jam session at any time, and there may be any musically practical number of participants
  • the techniques described above for obtaining and saving the current controller state can be employed in this application as well.
  • a participant could also request Internet site 903 to make a recording of the MIDI track for his session and send it to him at the end of the session.
  • Internet site 903 could of course use Archiver 904 to do this in the manner described for the distributed recording studio.
  • FIGs. 13-15 An encryption and decryption system which is able to provide the fundamental level of security needed for commercially viable distribution of MIDI tracks and files can be built according to the following principles:
  • the MIDI device must receive an encrypted track or file as input and produce as output either a digitized waveform specification of the output of the MIDI device or the audio signal itself.
  • the MIDI device will produce the audio signal as its output; however, the fact that the waveform equivalent of the MIDI file or track is so much larger than the MIDI file or track provides useful protection for the MIDI publisher.
  • a decrypter that is an integral part of the MIDI device is one whose output cannot be tapped either as a decrypted MIDI track or file or as a MIDI stream by an ordinary user without destroying the hardware.
  • the decrypter and other components of the MIDI device must be implemented as a single executable code module whose subcomponents cannot be replaced at runtime by corresponding components provided by the user.
  • the other components cannot be implemented using DLLs for generating MIDI streams from MIDI files or tracks or waveforms from MIDI streams
  • FIG 13 shows a MIDI encryption and decryption system which conforms to the above principles
  • sources 1303 there are basically two kinds of sources, real-time sources 1305, in which MIDI tracks and files are produced from MIDI streams 111, and stored sources 1315, where previously created tracks and files are stored
  • a real time source will typically be connected directly to a MIDI device 113 which is producing a MIDI stream 111 That MIDI stream is converted to a MIDI track 105 by stream-to-track transformer 1309, which will typically be a MIDI sequencer 511 and will then go to encrypter 1311, which will encrypt the MIDI track Encrypted MIDI track 1313 may then be stored on a medium such as a floppy disk, or it may be sent to network 1211 as it is created As described in the parent of the present application, one case where the latter is done is when a recital is being performed at source 1305 and being distributed via network 1211 as it is being performed What is important with regard to real-time source 1305 is that only encrypted MIDI tracks and files leave real-time source 1305
  • Stored sources 1315 simply contain encrypted MIDI tracks 1313 or files 1319 stored on storage media in a device that has access to network 1211
  • stored source 1315 will not contain any decrypter, and will simply answer requests for MIDI songs from destinations 1335 by transmitting encrypted tracks or files for the songs via network 1211 to the requestor destination 1335
  • Network 1211 may be any kind of LAN or WAN, but in a preferred embodiment, it is a network with non-real-time protocols such as the Internet Techniques for transferring MIDI tracks and files via the Internet are described in detail in the parent and grandparent of the present application
  • a destination 1335 may either receive encrypted MIDI files 1321 or encrypted MIDI tracks 1313.
  • the destination appears as a MIDI file player 1331 and in the latter as a MIDI track player 1332.
  • track player 1332 plays tracks as they are received from network 1211 and does not store the track being played beyond what is necessary to overcome network delays.
  • File player 1331 plays from a stored encrypted MIDI file, as may be seen from the presence of encrypted file 1319 in file player 1331.
  • Most destinations 1335 will of course be able to function as either a track player or a file player.
  • the player may receive the file via network 1211, or may have a disk drive for playing diskettes or CD-ROMS with MIDI files on them.
  • a decrypting synthesizer 1323 In the preferred embodiment, this is an executable code module that has integral to it a decrypter 1325, a MIDI track to stream transformer 1327, and at least a wave generator 1339 The latter component transforms a MIDI stream 111 into waveforms of the kind interpreted by sound cards It is advantageous if sound generation device 1337, which produces audio from waveforms, is also integral to the module As indicated above, what is meant in this case by "integral to the module” is that the ordinary user of the module cannot access the decrypted MIDI track, the MIDI stream made therefrom, and, most advantageously, also the waveforms, from outside the module, and further cannot replace components of the module with other components at run time As can be seen from FIG 13, decrypting synthesizer 1323 conforms to the general principles set forth above in that it receives encrypted tracks 1313 as input and produces either analog audio output 1227 or digital waveforms 1334, depending on whether
  • Encryption of MIDI tracks or files may be done using any known data encryption method As shown in FIG. 14, encryption is typically done using a software or hardware encryption device which takes as its inputs MIDI track 105 (or a MIDI file 103) to be encrypted and an encryption key 1401 and outputs an encrypted track 1313 (or file 1319).
  • source encryption key 1401 will be unique to a publisher, but will be so chosen that decrypting keys for track 1313 may be easily distributed to many destinations 1335.
  • source encrypting key 1401 is simply a Universal Resource Locator (URL) 1405 which identifies source 1303 in the Internet. URL 1405 is used as a public key in a public key encryption system, and all destinations 1335 have private keys which enable them to decrypt MIDI files and tracks encrypted with URL 1405.
  • URL Universal Resource Locator
  • FIG. 15 shows a detail of decrypting synthesizer 1323, showing embodiment 1329, in which the output of decrypting synthesizer 1323 is waveform descriptions 1334, or embodiment 1523, in which the decrypting synthesizer includes sound generating device 1517 and outputs audio analog signals 1227.
  • decrypter 1325 includes decryption device 1511 and data structures for handling decryption keys.
  • Decryption device 1511 includes decryption device 1511 and data structures for handling decryption keys.
  • Decryption device 1511 may be hardware or software that decrypts data which has been encrypted according to the encryption technique used in encrypter 1311.
  • Decryption device 1511 takes as its inputs an encrypted MIDI track 1213 and a key 1509 and produces an unencrypted MIDI track 105 which is provided as it is produced to track to stream transformer 1327.
  • decrypter 1325 can decrypt MIDI tracks or files from several sources. In order to do this, it maintains a key list data structure 1503 in which there is an entry 1505 for each source. The entry includes a specifier for the source 1507 and a key 1509 that decrypter 1511 currently uses to decrypt MIDI tracks or files from that source. Which key is to be used to decrypt a given file or track is determined by means of a source specifier 1501. Source specifier 1501 may be part of a header received with the MIDI track or file, or it may be obtained when a user of a destination 1335 establishes a connection to a source via network 1211. In either case, source specifier 1501 is used to locate entry 1505 for that source and key 1509 in that entry is used to decrypt the track or file.
  • a problem in the implementation of decrypting synthesizer 1323 is keeping the keys 1509 secret.
  • the problem has two parts: obtaining the keys in the first place and storing them securely.
  • both problems are solved by making key list 1503 an integral part of the executable code for decrypting synthesizer 1323. Since there is no separate storage for the keys, a normal user will not be able to locate them in memory or on disk.
  • This solution takes advantage of the fact that the preferred embodiment is implemented as part of a plugin for a browser and is obtained by using the browser to download the plugin If new sources are added or the key for a source is changed, the user can get the new keys simply by downloading a new version of the plugin.
  • keys might be downloaded and loaded into key list 1503 as part of a protocol by which a user of a destination 1335 signs up for MIDI tracks or files from a given source 1303.
  • the key would need to be encrypted when it was sent across network 1211 and decrypter 1325 would need to be able to decrypt the key.
  • Schneier, supra describes a number of techniques for key management that could be employed in system 1301 If the keys 1509 are not stored as part of the program for decrypting synthesizer 1323, they will need to be stored in persistent storage belonging to the system upon which destination 1335 is implemented, and will need to be encrypted when they are stored.
  • keys may have different granularities.
  • a given key may permit decrypter 1325 to decrypt everything received from a given source 1305 or only certain things, for example a given song or a given recital. In the later cases, the key is best transferred as part of the protocol for purchasing the song or recital.
  • the relationship between a key 1509 and decrypting synthesizer 1325 may also vary.
  • One simple approach is to associate a given key 1509 with a given copy of the plugin containing decrypting synthesizer 1323; in the context of single-user systems, this is perfectly adequate.
  • the association is dynamic (for example with the instantiations), the association would be done as part of the protocol for purchasing a song or recital.
  • decrypting synthesizer 1523 Operation of decrypting synthesizer 1523 is as follows: as decryption device 1511 decrypts MIDI events, it immediately provides them to track to stream transformer 1327, which maintains only enough of a buffer of MIDI events to deal with the delay problems described in the parent of the present application and with multiple events which occur at substantially the same point of time in the MIDI stream.
  • the buffer is of course part of the address space of the task which is executing the software for destination 1335 and is not accessible to other processes in the system.
  • stream-to-waveform transformer 1512 As track to stream transformer 1327 produces MIDI stream 111, it immediately provides it to stream-to-waveform transformer 1512, which produces a stream of digitized representations 1334 of the waveforms that would be produced by MIDI devices responding to MIDI stream 111.
  • the waveform representations are in turn sent as they are produced to hardware driver 1515, which puts the representations into the form required for sound generating device 1517, which actually generates the audio signals 1227 to which loudspeaker
  • sound generating device 1517 is a sound card with a digital signal processor; in others, sound generating device may be the microprocessor upon which the software by means of which destination 1335 is implemented is executing. In the latter case, shown in FIG. 15 as 1523, there is no point in decrypting synthesizer 1323 at which a normal user has access to a form of the original encrypted MIDI track or file which is useful for making digital copies thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Electrophonic Musical Instruments (AREA)

Abstract

Techniques de lecture et de répartition de pistes MIDI (interface numérique pour instruments de musique) en temps non réel tel que le réseau Internet. L'une des techniques permet de commencer la lecture d'un fichier MIDI multi-piste (203) reçu par le réseau Internet avant que la totalité du fichier ne soit reçue. D'autres techniques permettent de lire des pistes MIDI générées en temps réel puis distribuées sur le réseau Internet. Lesdites techniques garantissent que les temporisations réseau attendues ne provoquent pas de dépassement de capacité négatif dans la mémoire intermédiaire MIDI, offrent une possibilité de lire une chaîne MIDI 'sans fin' (111) et fournissent aux joueurs des moyens de collaboration et même de participation à des concerts de jazz improvisés sur le réseau Internet. Les techniques décrites dans la présente invention permettent d'inclure des décrypteurs dans des synthétiseurs MIDI et d'employer lesdits décrypteurs dans le contexte de chaînes MIDI codées reçues sur le réseau Internet.
PCT/US1997/016790 1996-09-20 1997-09-22 Procedes et appareil de codage et de decryptage des fichiers WO1998012876A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US08/716,949 1996-09-20
US08/716,949 US6317123B1 (en) 1996-09-20 1996-09-20 Progressively generating an output stream with realtime properties from a representation of the output stream which is not monotonic with regard to time
US08/732,949 1996-10-17
US08/732,949 US5819108A (en) 1996-10-17 1996-10-17 Programming of software into programmable memory within a peripheral device
US08/811,976 1997-03-05
US08/811,976 US5883957A (en) 1996-09-20 1997-03-05 Methods and apparatus for encrypting and decrypting MIDI files

Publications (1)

Publication Number Publication Date
WO1998012876A1 true WO1998012876A1 (fr) 1998-03-26

Family

ID=27418963

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/016790 WO1998012876A1 (fr) 1996-09-20 1997-09-22 Procedes et appareil de codage et de decryptage des fichiers

Country Status (1)

Country Link
WO (1) WO1998012876A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1403847A3 (fr) * 2002-09-24 2007-01-17 Yamaha Corporation Système, procédé et programme d'ordinateur assurant la sécurité d'utilisation de fichier de données d'exécution musicale
US7220909B2 (en) 2004-09-22 2007-05-22 Yamama Corporation Apparatus for displaying musical information without overlap

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5058159A (en) * 1989-06-15 1991-10-15 Macrovision Corporation Method and system for scrambling and descrambling audio information signals
US5491751A (en) * 1993-05-21 1996-02-13 Coda Music Technology, Inc. Intelligent accompaniment apparatus and method
US5524051A (en) * 1994-04-06 1996-06-04 Command Audio Corporation Method and system for audio information dissemination using various modes of transmission
US5617476A (en) * 1993-07-12 1997-04-01 Matsushita Electric Industrial Co., Ltd. Audio scrambling system for scrambling and descrambling audio signals

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5058159A (en) * 1989-06-15 1991-10-15 Macrovision Corporation Method and system for scrambling and descrambling audio information signals
US5491751A (en) * 1993-05-21 1996-02-13 Coda Music Technology, Inc. Intelligent accompaniment apparatus and method
US5617476A (en) * 1993-07-12 1997-04-01 Matsushita Electric Industrial Co., Ltd. Audio scrambling system for scrambling and descrambling audio signals
US5524051A (en) * 1994-04-06 1996-06-04 Command Audio Corporation Method and system for audio information dissemination using various modes of transmission

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1403847A3 (fr) * 2002-09-24 2007-01-17 Yamaha Corporation Système, procédé et programme d'ordinateur assurant la sécurité d'utilisation de fichier de données d'exécution musicale
US7371959B2 (en) 2002-09-24 2008-05-13 Yamaha Corporation System, method and computer program for ensuring secure use of music playing data files
US7935878B2 (en) 2002-09-24 2011-05-03 Yamaha Corporation System, method and computer program for ensuring secure use of music playing data files
CN101266785B (zh) * 2002-09-24 2013-05-01 雅马哈株式会社 电子音乐系统
US7220909B2 (en) 2004-09-22 2007-05-22 Yamama Corporation Apparatus for displaying musical information without overlap

Similar Documents

Publication Publication Date Title
US5883957A (en) Methods and apparatus for encrypting and decrypting MIDI files
US6067566A (en) Methods and apparatus for distributing live performances on MIDI devices via a non-real-time network protocol
US6088733A (en) Communications of MIDI and other data
US6009457A (en) Distributed real-time communications system
US6093880A (en) System for prioritizing audio for a virtual environment
US6975995B2 (en) Network based music playing/song accompanying service system and method
US7081580B2 (en) Computing device to allow for the selection and display of a multimedia presentation of an audio file and to allow a user to play a musical instrument in conjunction with the multimedia presentation
JP4794047B2 (ja) 保護されたデジタルファイル配信方法
US7030311B2 (en) System and method for delivering a multimedia presentation to a user and to allow the user to play a musical instrument in conjunction with the multimedia presentation
US6969797B2 (en) Interface device to couple a musical instrument to a computing device to allow a user to play a musical instrument in conjunction with a multimedia presentation
US6953887B2 (en) Session apparatus, control method therefor, and program for implementing the control method
JPH1173182A (ja) 音楽作品ファイルを作成、配布、記憶、及び、実行するシステム並びに方法
US20040011190A1 (en) Music data providing apparatus, music data reception apparatus and program
JP2009535988A (ja) データ信号を処理するシステム及び方法
JP5803056B2 (ja) 音響処理システムおよび音響処理方法
KR100819775B1 (ko) 네트워크 기반의 음악연주/노래반주 서비스 장치, 시스템, 방법 및 기록매체
US6627807B2 (en) Communications apparatus for tone generator setting information
WO1998012876A1 (fr) Procedes et appareil de codage et de decryptage des fichiers
JP3685805B2 (ja) 分散型リアルタイム通信システム
JP4126246B2 (ja) 演奏データ通信システム
JP4131678B2 (ja) 演奏データ通信システム
JP2004093975A (ja) 通信端末及びプログラム
Iazzetta et al. Downloading Musical Signs
Dannenberg et al. Scaling up live internet performance with the global net orchestra
JP4090925B2 (ja) 演奏データ送信装置、通信システム、送信方法及びプログラム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: CA

NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 1998514953

Format of ref document f/p: F

122 Ep: pct application non-entry in european phase