h a l f b a k e r yIf you need to ask, you can't afford it.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
"Module files store several patterns or pages of music
data
in a form similar to that of a spreadsheet. These
patterns
contain note numbers, instrument numbers, and
controller
messages. The number of notes that can be played
simultaneously depends on how many tracks there are
per
pattern."
- Wikipedia
Module music files tend to be a static affair, played from
start to end.
What would be nice, is a music file type that accepts
'environmental variables' to dynamically respond to the
new variables. This could allow for responding to user
mood, or to game events, or a new email.
This can be as simple as repeating certain loops, to
totally synthesising new songs on the fly. The music
player would have a Virtual Machine to allow for these
complexities.
----
From reddit thread:
Such standard would support two formats:
A barebone bytecode file for generating PCM on the fly.
Good for pure algorithmic music on micro controller.
A 7zipped archive contain both the bytecode program
and ogg samples it can manipulate. Good for more
traditional tracker music (But way more extend-able).
---
edit: Changed from interpreter based idea, to VM based
idea. Since it will allow for variety of programming
language to compile to same bytecode.
Is there any Turing Complete music tracker format?
http://www.reddit.c...sic_tracker_format/
Thread in reddit. Developing the idea further. [mofosyne, Jul 07 2014]
[link]
|
| |
Other unintentional significance of this concept.
Since this music file should be fully Turing complete
interpreter, if it can also accept keyboard input then
this music format would also be capable of being a
'sound based game', e.g. rhythm game or games for
the blind. |
|
| |
//From reddit thread: Such standard would support two formats:// |
|
| |
From HalfBakery Help page: Ideas for inventions for the halfbakery should be original to the poster. |
|
| |
I don't get the comments about this not being his
idea. It appears that he posted the idea here on
April 14th and got no interest. Then a few days
ago he posted the idea to reddit with a few
additions then came back here and updated his
idea to include those. |
|
| |
[mofosyne], was there some particular situation
you had in mind where this would be really useful?
As it is, I don't see a great need. If you want
music, there are many formats available, if you
want a program that outputs sound, there are
many programming languages with libraries to
make sound. |
|
| |
Well I think it's a great idea. |
|
| |
A few years ago I made a game with an endless music track - which was patched together from several loops derived from a tune I'd licensed. It wasn't easy to do, and didn't respond to how the player was doing. |
|
| |
If there was a standard format which could receive 'events', then I can see that working really well. We need a clear division between what the musician and the programmer would do. With that in mind, programming on the music side needs to be straightforward - at least for the minimum necessary. |
|
| |
I don't think viruses need to be a problem. Turing complete doesn't mean universal access. If the music scripting language can't read arbitrary data or output anything other than the generated music (and perhaps some sort of internal state report to the parent program) then the worst that can happen is an annoying noise. |
|
| |
I think it's eminently doable as a middleware system. |
|
| |
[scad] ah, I see... though I don't think the reader should have to investigate off-site threads and notice dates and things. |
|
| |
So what's the actual idea ? |
|
| |
Well, in between "modular file" and "xm", which I don't know/care what that is [edit: sequencer file], and "7zip" which is a compression algorithm, and "bytecode" which is a compressed source code, and Turing which was some genius back in the '50s and the name of an intelligence test for machines, PCM which is a sample compression method (I think), and to top it all off "ogg file" which is something to do with Macintoshes. whoops, forgot "music filetype that accepts variables...". How'bout one that doesn't. |
|
| |
//// ...endless music track - which was patched together from several loops...////
//But this is well baked in many games.// |
|
| |
The point was, doing it was hard. Because that use hadn't been anticipated, I had to fiddle around to get the data into a suitable form. *And* it doesn't do everything encapsulated in the idea. |
|
| |
//So what's the actual idea ?// |
|
| |
I think the problem here is that the description became bogged down in technical details - really quite unnecessarily. |
|
| |
As I see it, mofosyne's proposal is essentially to create a standard for interworking between programmers and musicians. |
|
| |
Perhaps I can describe how I see the issue, with regard to the current state of the videogame industry[1].
At the moment, small game creators can buy in (licence) music. This can be as tracks (which generally are 1 to 5 mins long) and/or loops (which may be 30 secs long or so). The closest they can get to this idea is to have a 'seamless set' of loops, and switch between them[2].
Large game creators on the other hand can bring in a salaried composer, and can then get exactly what they want. I have played games where the music adapts to the play, but it's quite rare. As far as I know totally ad-hoc - that is, the music system is written specifically for the one game. This means there isn't a large pool of talent for writing adaptable music like there is for graphic design, 3D modelling or other areas where there are widely-used tools. |
|
| |
With mofosyne's system, a musician could create an adaptable track, which could morph between different tunes, styles or ambiences based on inputs from a game. The reason for specifying "Turing completeness" is so that any desired effect can be generated.
The trick to it would be to make it easy for composers to do the obviously desirable things without having to learn a tonne of programming details. |
|
| |
[1] mofosyne mentions other possibilities, but games seem the obvious initial market to me.
[2] - unless they have taken enough levels in both composing and coding. |
|
| |
Ah, thanks... that makes a bit of sense. So something that has the PC react musically to input ? the post looks like somebody just dumped a bunch of buzzwords and acronyms into a blender (not saying I don't have a few like that, doesn't mean I enjoy reading same [-] ). |
|
| |
So your spreadsheet gives a "da da da DAAHHHH" when the entry and verify columns match and a "wah wah waaaahhh" and a bit of snickering when they don't. Lurvely ;D |
|
| |
Walk through the room in the FPS and the soundtrack depends on health, weapon-selected, map location, enemies/friends/items seen (and unseen - foreshadowing), task-completion, game-level, difficulty-setting, avatar, etc. |
|
| |
I sortof get it, but fail to see what all the acronyms and buzz-phrases have to do with the idea. |
|
| |
It's not that difficult at a coding level... actually it's not that difficult on a music level either, just lots of work. |
|
| |
A rather distorted use of "Turing completeness". |
|
| |
Who could possibly forget the old Vapours song, "I'm Turing Japanese", early indications of a possible international market... |
|
| |
Wouldn't be hard to make at all. Very possible. Similar things exist: there is a machine that makes (appropriately, and I think) jazz songs. You just leave it on and it keeps going. Having input on one of these bad boys to riff off of... that's new. |
|
| |
Good luck with it, tell me when you've paid $190 for a smart guy programmer to do it. |
|
| |