There are many facets that establish music an albums selling capacity ranging from style, originality, and marketing strategy to the sound quality and distribution medium used. Musicians, production engineers, and artists use numerous computer software applications that aid in the production of modern music. However, few of the software applications they rely on are strongly tied together in a cohesive form. The most common links between them are common file formats such as WAV, mp3 and PCM. Engineers also use many different platforms like the Macintosh, Windows PC, and Linux computers. The music industry needs to go to a unified open architecture framework for its application platform because it will allow future expansions to be accomplished more easily, provide increased productivity throughput and allow more descriptive loop based music. I propose for discussion the following guides:
All facets of music production should to be connected together in one product framework because this makes logical sense in software engineering architecture and as well in usability. A framework will allow numerous advancements to occur within the products offered for music production because shared knowledge will be massed. Imagine a music production platform that, through add ons and integrated in place downloads, can be configured to be a workstation for music authoring, a mastering production studio, artistic video editing suite or any combination of the technologies in a project form. All of these applications do exist in one variation or another on PCs, Macs or Linux machines yet are typically separate executables. While at times the complexity of the individual components may be weighty for a single manufacturer to deliver, when an open source component based architecture is used, tying these third party applications together will be easier. By combining the applications together under one framework, new in roads of data sharing and creativity can be achieved that was not possible before. The strongly linked music interface will save enormous amounts of time by allowing data to be operated on while in a parsed stream. As well, advanced features that were not considered viable will now be possible such as providing project management of remote artists.
PCM audio data, midi loop composition and parameters for digital signal processing algorithms can be utilized and multiple states can be maintained for individual items by exposing the information through a robust API. The communication of the individual items should be accomplished by standardized and flexible structures. I suggest a structure that is a binary form of XML, that is, elements inside the structure contain name, type, size and value data. The parameter settings can be maintained in a stack or vector array. By tying the information together in a relational way such as parent and child node relationships, cascading changes to final aural rendered targets will be easier. The rendering can also be targeted for server or local processing by maintaining state.
For example, when attributes change that effect the composition of a sound loop, the linked audio rendering and all of its child versions can be automatically updated if so desired. This allows an artist to spin several variations of the same loop with augmentations applied to each version. Some versions could be mixes with other loops or include sound effects processing that denote artistic style. The same goes for the audio effects processor objects. When an effect chain process is updated, the related loops that use the effect could also be updated in the rendering.
The application framework for music production should be tailored for large amounts of shared data as well as allowing several states for the item to exist. This type of persistence is known as relational data nodes or linked lists in computer science. The framework must support the application layer by exposing the hardware resources available on the machine in an effective way but also be efficient in not slowing down the traffic to the hardware devices it self. As well the implementation must be robust enough to recognize and categorize VSTs. Some VSTs will be representative of hardware resources while others may be software implementations. And future VSTs may even present themselves as an Internet rendering source. What ever the case, the framework must supply APIs that operate effectively for all the modern component architectures dealing with DSP.
The portion of the framework that exposes the hardware resources must not be burdensome to the CPU. It should be a light implementation that does not constrict data flow or cause any bottle necks. For example, Microsoft Direct X consists of several components. One is named HAL. HAL stands for Hardware Abstraction Layer. By abstracting the hardware from the application using a middle layer allows greater flexibility in supporting multiple platforms and features. As well, because the component is a thin pass through layer, that is function inlines are used, performance is optimal. And this is what is needed for real items rendering platforms.
In music production, since the data being composed and operated on is almost never textual, a heavy graphics presentation is always utilized. As well the platform should be designed to be operated using a pen stylus touch. Multiple platforms of the framework should be created to allow the portability to exist across platforms. Java could be a good choice for base engine, but JINI should be used for all hooks into the hardware. But in the end, I believe performance may bottle neck the Java implementation. To compensate the framework could be designed so that a standard set of video interface functions are available. These functions will be used to generate the visual interface of the panel. The core logic, a C++ core logic, should be written in ANSI standard C so that multiple platform targets can be generated. GCC is such a compiler that will generate machine code for multiple targets. This does however, mean that the framework must be robust in its implementation. I propose that three platforms are supports. As well, Java could still be included for applications that are not specifically related to music rendering. VLISM is the best solution. Be sure to include a robust JIT compiler. There may be one that is available that uses GCC as its foundation. VSTs should be separated into two distinct layers, the interface rendering, and the DSP logic code.
These features are far reaching. And since the three major platforms supported are Windows, Mac, and Linux; in that order, consideration for multiple platforms may be a product of OO design on the first release only. Shipping multiple platforms does not need to be the target of the first production. As any good software engineer knows, limitation of scope and staged releases are essential to providing products on time and with durability. Controls that are common should also be implemented; dials, gauges, buttons, trees, etc. To provide backwards compatibility the framework should expose a device context (DC) or a direct X buffer to render in and do so appropriately for each micro platform it supports (MAC, PC, Linux, or OS/2 dive etc).
The application framework must be open source to allow developers and researchers world wide implementation rights and development opportunities. Internationalization is a requirement. Do the code pages for right to left languages, English, Japanese, German, Chinese, Russian, French, Italian, Spanish and other popular human communication systems. It may be considerate to support text rendering of the panels as a pass through to machine translation on the web, or better provide a programmer tool that generates the appropiate resource files if they do not have professional translations. It must be professionally documented. The documentation must contain numerious implementation samples. The default platform should be available as a product installed with third parties. This will provide great competition to the music production software market. Eventually the platform will run standalone on a specialized Pentium V platform that is geared for music production. The coolest Korg Tablet PC ever built. Planning for the future is the key.
When described as a complete vision, offloading to internet rendering thru Smart WinSock VSTs will be the end goal if companies wanted to provide the thinnest portable. I can dream of the day when I lay under the tree and compose symphonies using a tablet PC and stylus. As well, providing a completely DHTML enabled music production studio would be possible with a networked rendering solution. By using a web browser, java applets should be used minimially because of the security restrictions now imposed by library computer systems. However, there are steps that can be accomplished in between this delivery while not detracting from the end goal but paving a future for it. Modifiying the modern systhesis hardware to build a networking resource will be a considerable engineering effort. Perhaps a specialized MIDI controller and sampler solution could be used in addition to routing technologies to support a step towards total integration. This will allow older Audio hardware to still be used. And in addition provide a standardized solution for networking MIDI enabled audio equipment.
The music application framework must be internet aware and provide access to remote data through the framework. Eventually when the entire musical production is an Internet Rendered task, all of the audio editing parameters, effects parameters and child node states will be maintained on the client interface and synchronized on to host when changes occur. A CRC change state implementation would be acceptable. In this case each user of the audio rending network will have a presistance cached or session on the host. Specialized audio editors will have to be written that facilitate the local client interface and remote DSP augmentations. Hopefully the framework will provide for this through its implementation of common controls. That is a PCM graphic editor with remote synchronization built in. C++ objects that allow the representation of selection data and parameter data to be syncronized through a socket connection should also be available in case the software application requires its own control implementation to be used.
eCommerce and Licensing management of the tool panels should be considered when building the Music Production framework. Including an solid encryption algorithm and communication layer will be essential. It will be used for very secure financial transactions. The system should also provide hooks for the book keeping of transactions for accounting purposes. This may be how some artists actually receive funds either as a collaboratory team member, from a record company or pay bills from a producer, promoter etc. The accounting aspect should be two way, debit and credit processing.
Renting specific panels or applications should be accounted for along with virus protection using secure digital software signatures. A database should be maintained on the server that allows browsing and aural samples of the instruments, effects, or panel's purpose. This will allow audio mastering suits to rent out their wares and talent resources on the web. And by allowing interaction, asset collaboration and team work a good production can be delivered.Developers will be required to register their items on the server. The server should be a trusted connection so server side virus scanning should be in place. As well, since malicious programs can be written without virus checkers being aware, developers should be authenticated and given unique digital signatures.
Allowing audio mixing of internet streaming sources real time will allow advanced usage of internet. 256kbs and 512kbs are solid formats and there are lossless compressions for audio as well. This will allow remote artists real time performance input via satellite, or internet. I can get a guitar riff from Eddie Van Inhale, or Ozzy and include it in my production. Complete with copyright, contracts, and documents signed. The collaboration aspect can bring many different artists together for a production that was not available before. An internet database should be maintained that allows scheduling and collaboration. By providing a server model, artists can be registered to their specific networked region area, language, and required fee. Real professionals are stinky sometimes so privatizing or securing access to some individuals may be needed. Since music is such a time sensitive communication form, a specialized interface should be written that allows collaboration of several remote sources by time synchronization.
An integrated platform will allow many new features and concepts to be communicated by the interface that was not fesible with past technologies. Although rewire and VST lead to this direction, integration within a desktop environment will make management of the assets more seamless. Seamless from start to final publishment considering the artist, record label, production engineers, and consumer. That is extremely important as a time saver and as a protection. The framework should track all files and assets associated with a song, album in a relational structure, using structures much like a database. Integration with internet communication will ease, teach and broaden the selection of tools by its users. So artists will be able to realize a more finite expression to their creativity not having to compromise as often.
The user's platform must be self maintaining as the general user profile will be less technically oriented. Asset management, file locations, directory pruning, emailing, virus scanning, backups and other realted administrator tasks should be as automated as possible.
An integrated platform in the software engineering capacity also means integration on a micro level. That is, effect DSP processors, instruments, and sequencer components all work together accepting shared memory resources and common interfacing language or structures. In an effort to produce a extremely robust platform, loose coupling and tight cohesion within objects or components should be the goal secondary to performance. So that, by small object implementations, reduction of errors can be achieved. As well, typically resource management is the main flaw in most applications, a set of APIs should be available as part of the framework that faciliate resource allocation and internally do error tracking. Providing fail safe operation is also implemented to a small degree by the abstraction of the parameters from the object itself within the framework's memory space. When a third party crashes, the information still presists within the framework's memory manager. The space should be cleaned and restarted, if appropiate.
Providing the turnkey framework solution of a Music Production Desktop is essential in capturing the market share and have something thatthe market will build upon. Many companies have tried and have come close, yet a total solution has not been provided that is encompasing. With the business knowledge and know how communicated from industry experts being implemented as business rules in software, the industry of looped based music will effectively be easier to navigate. Common tools do create massive awareness. By the solution I suggest, it can cut out middle men making expression and freedom of speech more attainable. While I am not suggesting the end of labels, I am suggesting that labels use the software. Their collection fee will be easier to attain, communication with their artist will be easier, and management can be more effective with less resources. You get more doe for doing less.
Each of these panels or applications needs to be implemented to include exported COM interfaces that support the Music Compilation Framework. The interface needs to be provided in such a way that allows the software manufacture minimal code changes to be included in the framework. I suggest a collaboration effort with the tool manufactures themselves to arrive at a standard. So Adobe Auditions sound editor, Steniburg's VSTs, Microsoft Front Page, and Protools can be used. As part of the base platform, perhaps several components can be included, like the sequencer for example. As well, the product should still operate on a stand alone basis.
With the platform existing as a unified production unit, authors will be more productive. Sound engineers will be able to communicate easier with the artist. Lawyers and content management staff will be able to secure assets and sign contracts. The artistic communication value will determine the appeal to its audience more directly by easing communication between all partners in the industry. And of course do not leave out internet browser support.