How about we invent a social network jamming platform(actually this has already been implemented by my team) fulfilling this need. Let's call it "WIJAM", meaning, "we instantly jam together over WIFI". The basic idea is easy: someone takes out his/her cell phone, opens an app or something, starts to create some melody, and the melody created is instantly mixed and broadcasted with the original background music and other melodies from other guys via a central speaker system.
But there are many problems underlying this scenario, and these problems lead to deeper research under the topic. The first problem naturally pop out is: do they really know how to jam? A huge problem. Assuming some of them are musical novices, they may have some very good music ideas in mind, but don't know how to express on traditional instrument layout such as a keyboard. OK, maybe we provide them with a fix musical scale, say a pentatonic scale or Ionian scale, so that they are within the scale. Then what about the key? Some simple background music use only a fix key without modulation. Even in with such background music, the novices still need to choose a key to apply the scale. How is it possible? Not to mention those grooves that change keys or even change available scales. No, we cannot let users to determine such a lot of things, we should leave them as comfortable and enjoyable as possible. This leads to the idea of a master controlling system to instantly assign keys and scales to all the users. Note that the final outcome of the jamming is playbacked via central speaker, this master system is also in charge of collecting the performance from players and distribute them to the speakers.
Yet this is far from the end of the story. As you know, the touch screen of most mobile phone is relatively small. If you ever had an experience playing a mobile phone keyboard, you probably think of it a bad experience because the keys on the screen are too small to touch. Back to our scenario, what should the master actually assign to the users? A real piano keyboard contains 88 notes, containing approximately 7 octaves. The number of all the notes of a C Ionian scale(which contains 7 identical pitch class) is approximately 7*7 = 49. But obviously we cannot afford all of the 49 notes on a single cell phone screen. Note that most of the time piano players only focus on 2-3 octaves in the middle of the keyboard layout, namely they seldom go to the very low pitch or very high pitch part. Also note that our scenario has background music already, which probably contain the bass part. So we can safely omit 3 lowest octaves and 2 highest octaves, keeping about 2-3 octaves, which still have 14-21 notes. This amount of notes is good enough for normal expression. But then how should we place these notes within the touch screen?
Actually this is one of the crucial issues that determine the successfulness of this application. It should be admitted that up till now no final decision is made upon this issue. One simple way we adopted at the beginning is to evenly dividing the screen into 4-row 2-column. With this the user has 8 note to express at a time. The master has several 8-note patterns to be ready to assign to the users and each of these pattern is within a certain scale such as Ionian or Dorian. The advantage of this layout is every note has a relatively large touchable area, and the novice user's expression freedom is under controlled to be within a scaled 8-note. But the disadvantages seems outweigh the advantages. For those whose want more notes, they can't get it until the master assign a new pattern. For normal users, they cannot differentiate the notes until they play and listen. They'll soon feel boring when they realize it's non intuitive to control their own expression. There are two facets in the drawbacks described above: 1. the expert users want more freedom, they need detailed control panel; 2. normal users want more control over their expression, they need intuitive control panel.
To cater for both users, the system design rule "leave it for the user" need to be applied, namely, two layouts should be designed and let users choose their preference. For the expert users, a note-based layout should be designed. It contains 16 - 32 notes, and should be layout in a systematically way that is easy to start with and difficult to be virtuoso at the same time. For the novice users, a graphic-based, or drawing-based layout should be preferred. It maps the drawing to up and down of the melody line, which corresponds to the feeling expressed by the users. The algorithm will determine which pitch to use according to a certain chord-scale combination provided by the master. If you are keen enough, you may notice that there is an issue regarding the drawing-based interface: how can the user express "rhythm"?
One approach is to use finger motion to signal a note-on of the new note and note-off of the old note, where the new note is mapped to the new position of the finger. For instruments such as guitar and piano we don't even need to signal the note-off most of the time, and it will be signaled automatically after the note finish decaying. This seems a workable approach, which we haven't implemented yet. Another approach is to use one finger to signal the rhythm, another finger to draw the melody. This is also interesting and quite convenient indeed.
So much for the interface issue. What about the overall performance outcome of this system. How to make all the performances by an ad-hoc group of scattering experts or novices make sense, fit together, or at least, sound good. This problem is two-folded. The easier and more fundamental one is how to make the mixture sounds good, while the more difficult one is to let it makes sense.
So how? To tackle the "sound good" problem is relatively easy. It demands something called algorithmic mixing and mastering. Theoretically(I do not have any source at this statement), the sum of any number of channels of any sound can be made comfortable to human ear as long as it is well mixed and mastered, regardless of the underling musical structure(such as, chord progression) or whatever. Namely, we can always manage to make it sounds comfortable. But the problem is how. As this has not yet been implemented, so it cannot be told for the moment. But let's make some guess. Say for example a very simple algorithm would be to set the volume of every channel to 1/n, where n is the number of channel. This makes sense, but not an ideal solution, as you may argue that what if some of the channel have higher weight. So here comes the problem, how to determine which channel has a higher weight? One approach is again to leave it to the user, but since we assume most of the users are musical novice, it may not work as wished. Note that our scenario is public space jamming, which is very different from an on stage live performance. On stage performance yields a sense of being focused, while our scenario yields a sense of scattering, in which every one enjoy themselves being hidden instead of being watched. So the "weight" doesn't convey the same meaning as before. Interestingly, people participating in this jamming will probably also wish their performance be heard by all other people. By combining these two observations, we can safely derive a bottom line of the auto mixing and mastering mechanism, which is to let every player at least be able to hear their part of contribution from time to time. By this key finding, we can safely write an algorithm involving some randomness to implement this function. Not a big deal yet.
The big deal is how to make the outcome make sense. To make sense, a logical expression of music is needed. It's more than to comfort our ear, but to comfort our mind. Since the basic assumption is the participators mostly are musical novice, this problem becomes an algorithmic composition problem. It could be a classical algorithmic composition problem when the musical content involved are pitches and timbres of standard instruments, or it could also be a new algorithmic composition problem when more sound synthesis elements are involved. Again this could be divided into two sub-problems. To tackle the classical one, we should attempt a more strict algorithmic composition approach, which contains a lot of AI stuff and far from fully developed yet. The algorithmic composition techniques can be found in lots of literature. While a "modern" algorithmic composition" problem, which aims to output some modern musical style such as electroacoustic, is relatively easier as I see, because the aesthetics of these are much more subjective than those music within the range of classical music theory. And for implementing the algorithm, there are several ways, one way is to implement the algorithm on user's side, therefore perhaps every user when jamming is within their own algorithmic logic. But this has disadvantage as you may easily notice is that what if their "logic" collide with each other, so that the outcome of the jamming is not so pleasant? True! So we have another approach. In this approach, the algorithm is implemented within the master side, therefore master can cooperate all the users to create a piece of good music. If implementing like this, the master is actually an algorithmic composer and conductor as well. A third approach would be both master and users implement the algorithms, while there is a feedback channel from master to the user, with the feedback indicating the user's algorithm to make a certain change to adjust itself to the whole performance. I think the third approach is the optimal one. Talking more about this topic is out of my range of ability for the moment, so I'd better stop talking here.
And there are still other issues. The audio engine, for now this project uses AUPreset +AudioUnit+AVSesssion to make sound, the AUPreset file points to the prerecored instrument samples by Apple Garageband. I don't know whether this will be legal or not(but according to the official statement it seems legal). Anyway, a more interesting and challenging approach would be to try to use the mobile STK, mobile csound, or ChucK for sound synthesis. Hopefully with one of these engine the size of the app can be greatly reduced, and the app is filled with some of the most advanced stuff as well. Another issue is whether to use OSC instead of MIDI as the music performance transportation media, since it seems OSC has a lower network transport latency. We'll see. A third issue, which is a big one, is the evaluation issue, and I'm gonna use the next two paragraphs to discuss it.
This kind of work, if ever published to the academic journals or papers, will definitely confront a problem of evaluation. In other research areas, such as computer architecture, the evaluation can be done quite straight forward. There will be indexes indicating whether an architecture(or a certain architecture improvement) is good or not, the most widely used ones being "performance", which indicates how fast a system runs. While in the field of computer music, the evaluation problem becomes much more ambiguous. How to determine whether a computer music system is good or bad? To narrow down the range of discussion, in what sense can we say that a network collaborative system is good. One approach that can be found in many papers is to "let the audience judge". In these papers, the "feedback" of the audience is presented, some of them being the subjective feeling, some of them being advises, some of them may also be questionnaires. Similarly, in a paper I saw the evaluation method is to post the outcomes of the computer music system on the web and let viewers rate them. Besides, there is "let the participants judge" method. The logic behind these two mentioned evaluation methods are all quite natural and obvious, since music is a aesthetic process, the final judgement should be made by human being.
But there is still another approach, which should be called "machine appreciation". This method should be implemented with "machine listening " in a very high level sense. Ordinary machine listening only cares about the audio material and the structure behind the audio material, while machine appreciation should demand a higher level of machine listening which cares about the musical material and also the musical structure. Of course every thing can be scaled down to a simplest case. In the case of machine appreciation in the context of classical music structure expression, the simplest algorithm only needs to take care of whether the notes are within scale or whether the voice leading obeys the rules. But of course, as you will agree, this is far from enough. Whether machine is able to appreciate music is itself also a big big question to be answered.
Nevertheless, we can use machine to do some measurement, such as whether by doing such and such the users are becoming more active, or whether such and such can make a collaborative system being more responsive. These are something machine can absolutely do.
So much for the evaluation part. Now I guess I've already given an introduction to this collaborative music jamming application in small public space. I've discussed the big scenario, the role of master and users, the user interface issues, the output quality issue as well as the evaluation issue. With all of these, I guess an extremely great public space jamming application can be created! Hopefully it can be done soon!
If you are a "master" and looking for free jam along tracks or backing tracks, here are some great jam-along tracks:
http://www.wikiloops.com
to be continued...
But there are many problems underlying this scenario, and these problems lead to deeper research under the topic. The first problem naturally pop out is: do they really know how to jam? A huge problem. Assuming some of them are musical novices, they may have some very good music ideas in mind, but don't know how to express on traditional instrument layout such as a keyboard. OK, maybe we provide them with a fix musical scale, say a pentatonic scale or Ionian scale, so that they are within the scale. Then what about the key? Some simple background music use only a fix key without modulation. Even in with such background music, the novices still need to choose a key to apply the scale. How is it possible? Not to mention those grooves that change keys or even change available scales. No, we cannot let users to determine such a lot of things, we should leave them as comfortable and enjoyable as possible. This leads to the idea of a master controlling system to instantly assign keys and scales to all the users. Note that the final outcome of the jamming is playbacked via central speaker, this master system is also in charge of collecting the performance from players and distribute them to the speakers.
Yet this is far from the end of the story. As you know, the touch screen of most mobile phone is relatively small. If you ever had an experience playing a mobile phone keyboard, you probably think of it a bad experience because the keys on the screen are too small to touch. Back to our scenario, what should the master actually assign to the users? A real piano keyboard contains 88 notes, containing approximately 7 octaves. The number of all the notes of a C Ionian scale(which contains 7 identical pitch class) is approximately 7*7 = 49. But obviously we cannot afford all of the 49 notes on a single cell phone screen. Note that most of the time piano players only focus on 2-3 octaves in the middle of the keyboard layout, namely they seldom go to the very low pitch or very high pitch part. Also note that our scenario has background music already, which probably contain the bass part. So we can safely omit 3 lowest octaves and 2 highest octaves, keeping about 2-3 octaves, which still have 14-21 notes. This amount of notes is good enough for normal expression. But then how should we place these notes within the touch screen?
Actually this is one of the crucial issues that determine the successfulness of this application. It should be admitted that up till now no final decision is made upon this issue. One simple way we adopted at the beginning is to evenly dividing the screen into 4-row 2-column. With this the user has 8 note to express at a time. The master has several 8-note patterns to be ready to assign to the users and each of these pattern is within a certain scale such as Ionian or Dorian. The advantage of this layout is every note has a relatively large touchable area, and the novice user's expression freedom is under controlled to be within a scaled 8-note. But the disadvantages seems outweigh the advantages. For those whose want more notes, they can't get it until the master assign a new pattern. For normal users, they cannot differentiate the notes until they play and listen. They'll soon feel boring when they realize it's non intuitive to control their own expression. There are two facets in the drawbacks described above: 1. the expert users want more freedom, they need detailed control panel; 2. normal users want more control over their expression, they need intuitive control panel.
To cater for both users, the system design rule "leave it for the user" need to be applied, namely, two layouts should be designed and let users choose their preference. For the expert users, a note-based layout should be designed. It contains 16 - 32 notes, and should be layout in a systematically way that is easy to start with and difficult to be virtuoso at the same time. For the novice users, a graphic-based, or drawing-based layout should be preferred. It maps the drawing to up and down of the melody line, which corresponds to the feeling expressed by the users. The algorithm will determine which pitch to use according to a certain chord-scale combination provided by the master. If you are keen enough, you may notice that there is an issue regarding the drawing-based interface: how can the user express "rhythm"?
One approach is to use finger motion to signal a note-on of the new note and note-off of the old note, where the new note is mapped to the new position of the finger. For instruments such as guitar and piano we don't even need to signal the note-off most of the time, and it will be signaled automatically after the note finish decaying. This seems a workable approach, which we haven't implemented yet. Another approach is to use one finger to signal the rhythm, another finger to draw the melody. This is also interesting and quite convenient indeed.
So much for the interface issue. What about the overall performance outcome of this system. How to make all the performances by an ad-hoc group of scattering experts or novices make sense, fit together, or at least, sound good. This problem is two-folded. The easier and more fundamental one is how to make the mixture sounds good, while the more difficult one is to let it makes sense.
So how? To tackle the "sound good" problem is relatively easy. It demands something called algorithmic mixing and mastering. Theoretically(I do not have any source at this statement), the sum of any number of channels of any sound can be made comfortable to human ear as long as it is well mixed and mastered, regardless of the underling musical structure(such as, chord progression) or whatever. Namely, we can always manage to make it sounds comfortable. But the problem is how. As this has not yet been implemented, so it cannot be told for the moment. But let's make some guess. Say for example a very simple algorithm would be to set the volume of every channel to 1/n, where n is the number of channel. This makes sense, but not an ideal solution, as you may argue that what if some of the channel have higher weight. So here comes the problem, how to determine which channel has a higher weight? One approach is again to leave it to the user, but since we assume most of the users are musical novice, it may not work as wished. Note that our scenario is public space jamming, which is very different from an on stage live performance. On stage performance yields a sense of being focused, while our scenario yields a sense of scattering, in which every one enjoy themselves being hidden instead of being watched. So the "weight" doesn't convey the same meaning as before. Interestingly, people participating in this jamming will probably also wish their performance be heard by all other people. By combining these two observations, we can safely derive a bottom line of the auto mixing and mastering mechanism, which is to let every player at least be able to hear their part of contribution from time to time. By this key finding, we can safely write an algorithm involving some randomness to implement this function. Not a big deal yet.
The big deal is how to make the outcome make sense. To make sense, a logical expression of music is needed. It's more than to comfort our ear, but to comfort our mind. Since the basic assumption is the participators mostly are musical novice, this problem becomes an algorithmic composition problem. It could be a classical algorithmic composition problem when the musical content involved are pitches and timbres of standard instruments, or it could also be a new algorithmic composition problem when more sound synthesis elements are involved. Again this could be divided into two sub-problems. To tackle the classical one, we should attempt a more strict algorithmic composition approach, which contains a lot of AI stuff and far from fully developed yet. The algorithmic composition techniques can be found in lots of literature. While a "modern" algorithmic composition" problem, which aims to output some modern musical style such as electroacoustic, is relatively easier as I see, because the aesthetics of these are much more subjective than those music within the range of classical music theory. And for implementing the algorithm, there are several ways, one way is to implement the algorithm on user's side, therefore perhaps every user when jamming is within their own algorithmic logic. But this has disadvantage as you may easily notice is that what if their "logic" collide with each other, so that the outcome of the jamming is not so pleasant? True! So we have another approach. In this approach, the algorithm is implemented within the master side, therefore master can cooperate all the users to create a piece of good music. If implementing like this, the master is actually an algorithmic composer and conductor as well. A third approach would be both master and users implement the algorithms, while there is a feedback channel from master to the user, with the feedback indicating the user's algorithm to make a certain change to adjust itself to the whole performance. I think the third approach is the optimal one. Talking more about this topic is out of my range of ability for the moment, so I'd better stop talking here.
And there are still other issues. The audio engine, for now this project uses AUPreset +AudioUnit+AVSesssion to make sound, the AUPreset file points to the prerecored instrument samples by Apple Garageband. I don't know whether this will be legal or not(but according to the official statement it seems legal). Anyway, a more interesting and challenging approach would be to try to use the mobile STK, mobile csound, or ChucK for sound synthesis. Hopefully with one of these engine the size of the app can be greatly reduced, and the app is filled with some of the most advanced stuff as well. Another issue is whether to use OSC instead of MIDI as the music performance transportation media, since it seems OSC has a lower network transport latency. We'll see. A third issue, which is a big one, is the evaluation issue, and I'm gonna use the next two paragraphs to discuss it.
This kind of work, if ever published to the academic journals or papers, will definitely confront a problem of evaluation. In other research areas, such as computer architecture, the evaluation can be done quite straight forward. There will be indexes indicating whether an architecture(or a certain architecture improvement) is good or not, the most widely used ones being "performance", which indicates how fast a system runs. While in the field of computer music, the evaluation problem becomes much more ambiguous. How to determine whether a computer music system is good or bad? To narrow down the range of discussion, in what sense can we say that a network collaborative system is good. One approach that can be found in many papers is to "let the audience judge". In these papers, the "feedback" of the audience is presented, some of them being the subjective feeling, some of them being advises, some of them may also be questionnaires. Similarly, in a paper I saw the evaluation method is to post the outcomes of the computer music system on the web and let viewers rate them. Besides, there is "let the participants judge" method. The logic behind these two mentioned evaluation methods are all quite natural and obvious, since music is a aesthetic process, the final judgement should be made by human being.
But there is still another approach, which should be called "machine appreciation". This method should be implemented with "machine listening " in a very high level sense. Ordinary machine listening only cares about the audio material and the structure behind the audio material, while machine appreciation should demand a higher level of machine listening which cares about the musical material and also the musical structure. Of course every thing can be scaled down to a simplest case. In the case of machine appreciation in the context of classical music structure expression, the simplest algorithm only needs to take care of whether the notes are within scale or whether the voice leading obeys the rules. But of course, as you will agree, this is far from enough. Whether machine is able to appreciate music is itself also a big big question to be answered.
Nevertheless, we can use machine to do some measurement, such as whether by doing such and such the users are becoming more active, or whether such and such can make a collaborative system being more responsive. These are something machine can absolutely do.
So much for the evaluation part. Now I guess I've already given an introduction to this collaborative music jamming application in small public space. I've discussed the big scenario, the role of master and users, the user interface issues, the output quality issue as well as the evaluation issue. With all of these, I guess an extremely great public space jamming application can be created! Hopefully it can be done soon!
If you are a "master" and looking for free jam along tracks or backing tracks, here are some great jam-along tracks:
http://www.wikiloops.com
to be continued...
tangkk
作为一个公共空间，如食堂或广场，你会听到一些音乐集中扬声器。大多数这些音乐的柔美风格。他们往往是缓慢和平稳，没有人声部分。有时候你会觉得像可以作出更好的背景气氛。或者有时候，你只是想显示你的存在，发送信息，或者做一些乐趣。或者在另外一些时候，你觉得无聊，只是想找到事做。那么也许你可以尝试在背景音乐的果酱，做一些有趣的事情发生。
怎么样，我们发明了一种社会网络干扰平台（实际上，这已经实现我的团队），满足这方面的需要。让我们叫它“WIJAM”，意思是“我们立即果酱一起通过WiFi”。基本的想法很简单：有人需要他/她的手机，打开一个应用程序或东西，开始创建一些旋律，和创建的旋律瞬间混合和原来的背景音乐和其他的旋律从其他人通过中央广播扬声器系统。
但也有许多相关问题，这种情况下，这些问题导致下深入研究的话题。自然蹦出来的第一个问题是：他们是否真的知道如何果酱？一个巨大的问题。假设其中一些音乐的新手，他们可能会在心中有一些很不错的音乐理念，但不知道怎样来表达对传统乐器，如键盘布局。好吧，也许我们为他们提供一个固定的音阶，说五声音阶或爱奥尼亚规模的，使它们的规模内。那么什么关键？一些简单的背景音乐只能使用一个固定的无调制的关键。即使在这样的背景音乐，新手还需要选择一个关键应用的规模。怎么可能？更不用提那些沟槽改变键，甚至改变现有的尺度。没有，我们不能让用户来确定这样的东西很多，我们应该让他们尽可能舒适和愉快的。这导致一个主控制系统瞬间指定键和扩展到所有用户的想法。此主站系统注意抗干扰playbacked通过中央扬声器的最终结果，是负责收集从球员的表现，并分发到扬声器。
然而，这是从故事的结局。正如你所知道的，大多数手机的触摸屏比较小。如果你曾经有过的经验，打手机键盘，你可能会想到一个坏的经验，因为在屏幕上的按键太小，无法触摸。回到我们的场景，主实际上分配给用户？一个真正的钢琴键盘包含88笔记，约含7个八度。所有的音符一个C爱奥尼亚规模（其中包含7个相同间距类）约7 * 7 = 49。但很明显，我们不能负担所有的49个票据在一个单一的手机屏幕。请注意，大部分的时间钢琴玩家只专注于2-3个八度的键盘布局中，即他们很少去非常低的沥青或非常高音部分。另外请注意，我们的场景已经有背景音乐，这可能包含低音部分。因此，我们可以放心地忽略3个八度最低和2个八度最高，保持约2-3个八度，哪还有14-21音符。此票据金额是不够好，正常的表达。但后来，我们应该如何将这些笔记内的触摸屏？
其实，这是确定这个应用得失的关键问题之一。应当承认，直至后，这个问题现在还没有作出最后决定。我们在开始时通过一个简单的办法是均匀分割屏幕分为4行2列。与此用户有8注意表达一次。 8音符主有几个模式，准备分配给用户和这些图案是在一定的规模，如爱奥尼亚海或多利安。这种布局的优点是每一个音符，有一个比较大的可触摸区域，和新手用户的表达自由是在控制范围内的比例8音符。但缺点似乎远大于优点。对于那些希望更多的音符，他们不能得到它，直到主机分配一个新的模式。对于普通用户来说，他们不能区分票据，直到他们播放和收听。他们很快就会感到无聊的时候，他们意识到这是不直观的控制自己的表达。在上面描述的缺点有两个方面：1。专家用户想要更多的自由，他们需要详细的控制面板; 2。普通用户想他们表达的更多的控制权，他们需要直观的控制面板。
为了配合这两个用户，系统设计规则“离开它为用户”需要被应用，即，两个布局应设计，让用户选择自己的喜好。专家用户，注意布局应设计。它包含16 - 32个音符，应该有系统的方式，是容易下手，不易被演奏家同时布局。对新手来说，一个基于图形或绘图，基于布局应该是首选。它映射图中的向上和向下的旋律线，对应于用户所表达的感觉。该算法将确定，间距根据由主机提供特定和弦规模组合使用。如果你是热衷的话，你可能会注意到，有问题基于绘图接口：用户如何快车“节奏”？
一种方法是用手指运动信号注意对新的音符，音符停止旧的注意，新的便笺被映射到新的位置的手指。乐器，如吉他和钢琴，我们不甚至需要注意关闭大部分时间信号，并，说明完成腐烂后，它会自动发出信号。这似乎是一个可行的办法，这是我们尚未实现。另一种方法是用一个手指到信号的节奏，另一个手指绘制旋律。这也是有趣，确实挺方便的。
这么多的接口问题。关于这个系统的整体性能结果。如何使所有的表演特设小组的专家或新手散射是有意义的，结合在一起，或者至少，声音好。此问题是叠成两折的。更容易和更根本的是如何使混合听起来不错，而它是有道理的，更困难的是让。
因此，如何？为了解决“声音好”的问题是比较容易的。它要求的东西称为算法的混音和母带制作。 （我没有任何来源在本声明）从理论上讲，任何声音的任何数目的信道的总和可以只要人耳舒适，因为它是很好的混合和掌握，无论下属的音乐结构（例如，和弦进行）或什么的。也就是说，我们总能设法使这听起来很舒服。但问题是如何。随着这种情况尚未付诸实施，所以它不能被告知的时刻。但是让我们做出一些猜测。说，例如一个很简单的算法，将每个通道设置音量的1 / n，其中n是通道号。这是有道理的，但不是一个理想的解决方案，因为你可能会争辩说，如果一些通道具有更高的权重。所以这里问题来了，如何确定哪个通道有一个较高的权重？一种方法是再次离开给用户，但因为我们假设大多数用户都是音乐的新手，希望可能无法正常工作。请注意，我们的场景是公共空间的干扰，这是非常不同的舞台上现场表演。在舞台上的表现产生了一个被聚焦的感觉，而我们的方案中产生散射，每一个享受自己被隐藏，而不是被监视感。因此，“减肥”不传达以前相同的含义。有趣的是，人们参与这种干扰可能会也希望所有其他人听到他们的表现。通过这两个观测相结合，我们可以放心地得出一个底线的自动混音和母带的机制，这是为了让每个球员都至少能不时听到他们的贡献的一部分。这个关键的发现，我们可以放心地写一个算法涉及一些随机性来实现这个功能。没什么大不了的。
大不了就是如何使结果有意义。为了便于理解，一个逻辑表达式的音乐是必要的。更重要的是，比安慰我们的耳朵，而是要安慰我们的心灵。由于参与者大多是音乐新手的基本假设是，这个问题变成一个算法的组合问题。这可能是一个经典算法的组合问题时所涉及的音乐内容的音高和音色的标准仪器，或涉及更多的声音合成元素时，它也可能是一个新的算法组合问题。同样，这可以分为两个子问题。为了解决经典，我们应该尝试更严格的算法的组合方法，其中包含了很多AI的东西，远未得到充分开发。算法作曲技法，可以发现大量的文献。虽然“现代”的算法作曲“的问题，其目的是输出一些现代的音乐风格，如电，相对容易些，因为我看到的，因为这些都是比音乐更主观的美学古典音乐理论的范围内。为实现该算法，有几种方式，一种方式是，以实现该算法在用户侧，因此，或许是每一个用户时，干扰是在自己的算法逻辑，但是这作为您可以轻松地发现缺点是，如果他们的“逻辑“相互碰撞，使堵塞的结果是不那么愉快吗？真！因此，我们有另一种方法，在这种方法中，该算法实现在主人身边，因此主人可以合作的所有用户创建了一块如果实施这样的，主是实际上是一个算法的作曲家和指挥家，以及第三个方法是将主机和用户实现算法，同时有一个从主机到用户的反馈渠道，反馈指示的好音乐。用户的算法做出了一定的变化自行调节整机性能，我认为第三种方法是最佳的。更多地谈论这个话题是我能力范围的时刻，所以我最好停止在这里谈论。
还有其他问题。音频引擎，现在这个项目，使用AUPreset + AudioUnit + AVSesssion使声，AUPreset的文件点的prerecored苹果的GarageBand乐器样本。我不知道这是否会是合法还是不合法（但根据官方的说法，似乎是合法的）。无论如何，一个更有趣和具有挑战性的做法是尝试使用移动STK移动与csound，或声音合成夹头。希望与这些发动机的应用程序的大小可以大大降低，并且与最先进的东西，以及一些填充该应用。另一个问题是，是否使用OSC代替MIDI音乐表演运输介质，因为它似乎OSC具有较低的网络传输延迟。让我们拭目以待。第三个问题，这是一个大的，是评价的问题，我会用接下来的两个段落讨论。
这样的工作，如果曾经出版的学术期刊或论文，肯定会面对一个问题的评价。评价等研究领域，如计算机体系结构，可以做得相当直截了当。会有指标架构（或某一个架构改进）是否是好还是不好，使用最广泛的是“业绩”，这表明一个系统运行的速度有多快。在电脑音乐领域，评价问题变得更不明确的。如何判断一个电脑音乐系统是否是好还是坏？为了缩小讨论的范围，我们在什么意义上可以说，网络协作系统是好的。一种方法，可以发现在许多论文是“让观众法官”。在这些文章中，“反馈”的观众，其中一些人的主观感觉，他们中的一些建议，也可能是他们中的一些问卷调查。同样，在一篇论文中，我看到的评价方法是电脑音乐系统成果发布在网站上，让观众率他们。此外，还有“让参与者法官”的方法。提到这两个评价方法背后的逻辑是很自然的和显而易见的，因为音乐是一种审美的过程，最后的判决应该由人类。
但是，仍然有另一种方法，这应该被称为“机鉴赏”。此方法应该在实现“听机”在一个非常高的层次感。普通机听只在乎背后的音频材料的音频材料和结构，同时该机的升值应该要求一个更高层次的机器听音乐素材的音乐结构关心。当然，每一种东西可以缩小到一个最简单的例子。在机器升值的背景下，古典音乐的结构表达的情况下，最简单的算法，只需要照顾票据是否是在规模或语音是否服从规则。不过，当然，你会同意，这是远远不够的。无论机是能够欣赏音乐，本身也是一个大的大要回答的问题。
不过，我们可以用机器做一些测量，如无论是通过做这样那样的用户正变得更加活跃，或者是否可以这样和那样的一个协作的系统，反应更灵敏。这些都是机器绝对可以做的东西。
这么多的评估的一部分。现在，我想我已经给介绍这种合作的音乐抗干扰应用在小型公共空间。我已经讨论过大的情况下，主站和用户的角色，用户界面问题，输出质量问题以及评价问题。所有这些，我想极大的公共空间干扰可以创建应用程序！希望可以很快完成！
未完待续...
作为一个公共空间，如食堂或广场，你会听到一些音乐集中扬声器。大多数这些音乐的柔美风格。他们往往是缓慢和平稳，没有人声部分。有时候你会觉得像可以作出更好的背景气氛。或者有时候，你只是想显示你的存在，发送信息，或者做一些乐趣。或者在另外一些时候，你觉得无聊，只是想找到事做。那么也许你可以尝试在背景音乐的果酱，做一些有趣的事情发生。
怎么样，我们发明了一种社会网络干扰平台（实际上，这已经实现我的团队），满足这方面的需要。让我们叫它“WIJAM”，意思是“我们立即果酱一起通过WiFi”。基本的想法很简单：有人需要他/她的手机，打开一个应用程序或东西，开始创建一些旋律，和创建的旋律瞬间混合和原来的背景音乐和其他的旋律从其他人通过中央广播扬声器系统。
但也有许多相关问题，这种情况下，这些问题导致下深入研究的话题。自然蹦出来的第一个问题是：他们是否真的知道如何果酱？一个巨大的问题。假设其中一些音乐的新手，他们可能会在心中有一些很不错的音乐理念，但不知道怎样来表达对传统乐器，如键盘布局。好吧，也许我们为他们提供一个固定的音阶，说五声音阶或爱奥尼亚规模的，使它们的规模内。那么什么关键？一些简单的背景音乐只能使用一个固定的无调制的关键。即使在这样的背景音乐，新手还需要选择一个关键应用的规模。怎么可能？更不用提那些沟槽改变键，甚至改变现有的尺度。没有，我们不能让用户来确定这样的东西很多，我们应该让他们尽可能舒适和愉快的。这导致一个主控制系统瞬间指定键和扩展到所有用户的想法。此主站系统注意抗干扰playbacked通过中央扬声器的最终结果，是负责收集从球员的表现，并分发到扬声器。
然而，这是从故事的结局。正如你所知道的，大多数手机的触摸屏比较小。如果你曾经有过的经验，打手机键盘，你可能会想到一个坏的经验，因为在屏幕上的按键太小，无法触摸。回到我们的场景，主实际上分配给用户？一个真正的钢琴键盘包含88笔记，约含7个八度。所有的音符一个C爱奥尼亚规模（其中包含7个相同间距类）约7 * 7 = 49。但很明显，我们不能负担所有的49个票据在一个单一的手机屏幕。请注意，大部分的时间钢琴玩家只专注于2-3个八度的键盘布局中，即他们很少去非常低的沥青或非常高音部分。另外请注意，我们的场景已经有背景音乐，这可能包含低音部分。因此，我们可以放心地忽略3个八度最低和2个八度最高，保持约2-3个八度，哪还有14-21音符。此票据金额是不够好，正常的表达。但后来，我们应该如何将这些笔记内的触摸屏？
其实，这是确定这个应用得失的关键问题之一。应当承认，直至后，这个问题现在还没有作出最后决定。我们在开始时通过一个简单的办法是均匀分割屏幕分为4行2列。与此用户有8注意表达一次。 8音符主有几个模式，准备分配给用户和这些图案是在一定的规模，如爱奥尼亚海或多利安。这种布局的优点是每一个音符，有一个比较大的可触摸区域，和新手用户的表达自由是在控制范围内的比例8音符。但缺点似乎远大于优点。对于那些希望更多的音符，他们不能得到它，直到主机分配一个新的模式。对于普通用户来说，他们不能区分票据，直到他们播放和收听。他们很快就会感到无聊的时候，他们意识到这是不直观的控制自己的表达。在上面描述的缺点有两个方面：1。专家用户想要更多的自由，他们需要详细的控制面板; 2。普通用户想他们表达的更多的控制权，他们需要直观的控制面板。
为了配合这两个用户，系统设计规则“离开它为用户”需要被应用，即，两个布局应设计，让用户选择自己的喜好。专家用户，注意布局应设计。它包含16 - 32个音符，应该有系统的方式，是容易下手，不易被演奏家同时布局。对新手来说，一个基于图形或绘图，基于布局应该是首选。它映射图中的向上和向下的旋律线，对应于用户所表达的感觉。该算法将确定，间距根据由主机提供特定和弦规模组合使用。如果你是热衷的话，你可能会注意到，有问题基于绘图接口：用户如何快车“节奏”？
一种方法是用手指运动信号注意对新的音符，音符停止旧的注意，新的便笺被映射到新的位置的手指。乐器，如吉他和钢琴，我们不甚至需要注意关闭大部分时间信号，并，说明完成腐烂后，它会自动发出信号。这似乎是一个可行的办法，这是我们尚未实现。另一种方法是用一个手指到信号的节奏，另一个手指绘制旋律。这也是有趣，确实挺方便的。
这么多的接口问题。关于这个系统的整体性能结果。如何使所有的表演特设小组的专家或新手散射是有意义的，结合在一起，或者至少，声音好。此问题是叠成两折的。更容易和更根本的是如何使混合听起来不错，而它是有道理的，更困难的是让。
因此，如何？为了解决“声音好”的问题是比较容易的。它要求的东西称为算法的混音和母带制作。 （我没有任何来源在本声明）从理论上讲，任何声音的任何数目的信道的总和可以只要人耳舒适，因为它是很好的混合和掌握，无论下属的音乐结构（例如，和弦进行）或什么的。也就是说，我们总能设法使这听起来很舒服。但问题是如何。随着这种情况尚未付诸实施，所以它不能被告知的时刻。但是让我们做出一些猜测。说，例如一个很简单的算法，将每个通道设置音量的1 / n，其中n是通道号。这是有道理的，但不是一个理想的解决方案，因为你可能会争辩说，如果一些通道具有更高的权重。所以这里问题来了，如何确定哪个通道有一个较高的权重？一种方法是再次离开给用户，但因为我们假设大多数用户都是音乐的新手，希望可能无法正常工作。请注意，我们的场景是公共空间的干扰，这是非常不同的舞台上现场表演。在舞台上的表现产生了一个被聚焦的感觉，而我们的方案中产生散射，每一个享受自己被隐藏，而不是被监视感。因此，“减肥”不传达以前相同的含义。有趣的是，人们参与这种干扰可能会也希望所有其他人听到他们的表现。通过这两个观测相结合，我们可以放心地得出一个底线的自动混音和母带的机制，这是为了让每个球员都至少能不时听到他们的贡献的一部分。这个关键的发现，我们可以放心地写一个算法涉及一些随机性来实现这个功能。没什么大不了的。
大不了就是如何使结果有意义。为了便于理解，一个逻辑表达式的音乐是必要的。更重要的是，比安慰我们的耳朵，而是要安慰我们的心灵。由于参与者大多是音乐新手的基本假设是，这个问题变成一个算法的组合问题。这可能是一个经典算法的组合问题时所涉及的音乐内容的音高和音色的标准仪器，或涉及更多的声音合成元素时，它也可能是一个新的算法组合问题。同样，这可以分为两个子问题。为了解决经典，我们应该尝试更严格的算法的组合方法，其中包含了很多AI的东西，远未得到充分开发。算法作曲技法，可以发现大量的文献。虽然“现代”的算法作曲“的问题，其目的是输出一些现代的音乐风格，如电，相对容易些，因为我看到的，因为这些都是比音乐更主观的美学古典音乐理论的范围内。为实现该算法，有几种方式，一种方式是，以实现该算法在用户侧，因此，或许是每一个用户时，干扰是在自己的算法逻辑，但是这作为您可以轻松地发现缺点是，如果他们的“逻辑“相互碰撞，使堵塞的结果是不那么愉快吗？真！因此，我们有另一种方法，在这种方法中，该算法实现在主人身边，因此主人可以合作的所有用户创建了一块如果实施这样的，主是实际上是一个算法的作曲家和指挥家，以及第三个方法是将主机和用户实现算法，同时有一个从主机到用户的反馈渠道，反馈指示的好音乐。用户的算法做出了一定的变化自行调节整机性能，我认为第三种方法是最佳的。更多地谈论这个话题是我能力范围的时刻，所以我最好停止在这里谈论。
还有其他问题。音频引擎，现在这个项目，使用AUPreset + AudioUnit + AVSesssion使声，AUPreset的文件点的prerecored苹果的GarageBand乐器样本。我不知道这是否会是合法还是不合法（但根据官方的说法，似乎是合法的）。无论如何，一个更有趣和具有挑战性的做法是尝试使用移动STK移动与csound，或声音合成夹头。希望与这些发动机的应用程序的大小可以大大降低，并且与最先进的东西，以及一些填充该应用。另一个问题是，是否使用OSC代替MIDI音乐表演运输介质，因为它似乎OSC具有较低的网络传输延迟。让我们拭目以待。第三个问题，这是一个大的，是评价的问题，我会用接下来的两个段落讨论。
这样的工作，如果曾经出版的学术期刊或论文，肯定会面对一个问题的评价。评价等研究领域，如计算机体系结构，可以做得相当直截了当。会有指标架构（或某一个架构改进）是否是好还是不好，使用最广泛的是“业绩”，这表明一个系统运行的速度有多快。在电脑音乐领域，评价问题变得更不明确的。如何判断一个电脑音乐系统是否是好还是坏？为了缩小讨论的范围，我们在什么意义上可以说，网络协作系统是好的。一种方法，可以发现在许多论文是“让观众法官”。在这些文章中，“反馈”的观众，其中一些人的主观感觉，他们中的一些建议，也可能是他们中的一些问卷调查。同样，在一篇论文中，我看到的评价方法是电脑音乐系统成果发布在网站上，让观众率他们。此外，还有“让参与者法官”的方法。提到这两个评价方法背后的逻辑是很自然的和显而易见的，因为音乐是一种审美的过程，最后的判决应该由人类。
但是，仍然有另一种方法，这应该被称为“机鉴赏”。此方法应该在实现“听机”在一个非常高的层次感。普通机听只在乎背后的音频材料的音频材料和结构，同时该机的升值应该要求一个更高层次的机器听音乐素材的音乐结构关心。当然，每一种东西可以缩小到一个最简单的例子。在机器升值的背景下，古典音乐的结构表达的情况下，最简单的算法，只需要照顾票据是否是在规模或语音是否服从规则。不过，当然，你会同意，这是远远不够的。无论机是能够欣赏音乐，本身也是一个大的大要回答的问题。
不过，我们可以用机器做一些测量，如无论是通过做这样那样的用户正变得更加活跃，或者是否可以这样和那样的一个协作的系统，反应更灵敏。这些都是机器绝对可以做的东西。
这么多的评估的一部分。现在，我想我已经给介绍这种合作的音乐抗干扰应用在小型公共空间。我已经讨论过大的情况下，主站和用户的角色，用户界面问题，输出质量问题以及评价问题。所有这些，我想极大的公共空间干扰可以创建应用程序！希望可以很快完成！
未完待续...
No comments:
Post a Comment