Topic: [DVC]DevCoin - Official Thread - Moderated - page 301. (Read 1058949 times)

Hello. If you'd like me to promote DEV coin feel free to PM me.

This is my twitter account where I do giveaways each day: https://twitter.com/ThisWeeksCoin

The more followers I get, the better. If I see there's a interest about DEV coin I'll start promoting it ASAP.

We would need a voice, and instructions about what it should say or do.

If your voice sounds different from some other voice, we ought at least have some generic modifiable voices or categories of voice, so we can categorise your voice as being either a voice of a certain category or a voice such as one might get using a certain set of filters/modifiers as input to a voice simulator.

Basically if voice synthesisers cannot yet produce a voice such as yours they need improving, and we want the open source version of such a voice-synthesiser.

We do not want a recording of you singing the song with your closed source human voice, we want the instructions as to how a voice is to be used to sing the song, maybe with some hints as to what kind of voice might perform it best for what kind of audience. (Maybe some audiences would prefer to hear it in a gruff voice, others in a soprano voice, others in a male voice, others in a female voice, others in a unisex or robotic voice and so on and so on.)

We want source code for how to go about singing such a song.

-MarkM-

I watch star trek all the time.

I like scifi, but don't let it influence my judgment when it comes to science, especially physics.

 

Please watch Star Trek: the new generation enough to observe at least one episode in which someone says "computer, some musicians, please" and presto, the computer creates some professional musicians. Maybe even simulations/emulations of specific musicians.

That is where we are aiming.

We ultimately want/need to be able to say "computer, show me Sinatra singing that. Hmm no, start over but lets try having Madonna sing it. Hmm, better, okay give me Blondie singing it..." and so on.

-MarkM-

Oh I absolutely care. There are classical pieces that sound divine when played with a harpsichord, but sound terribly inappropriate when played with a piano.  


You assume that every creation process is quantizable into things like strokes, movements, pressure points, whatever... this sure is true for code or text.

But much like some music instruments can't be controlled and reproduced by MIDI, many artforms have myriads of such miniscule subprocesses (the artist is often not even aware of) that you would need hypothetical scifi devices to be able to "catch" what happens during the creation process. (Earlier I heard you mention star trek replicators replicating a violin. I don't think wishful thinking about future developments will help us make good decisions about devcoins present.)

That is what we are trying to save other people from having to go through!

Yes, back in the dark ages before music software was free and open source, when music hardware was not free open source hardware you could print yourself using your home 3-D printer, and instruments were not free open source software or free open source instructions for free open source 3-D printers to print, you suffered horrible expense.

No one should have to go through that! This project is all about trying to ensure future generations will not have to go through that!

-MarkM-

For writing, think about fonts.

We do not care what font is used at display time to display an article, we are free to use any font we choose to use.

Publishers though would prefer we only get a scan of a printout of an article, and font publishers would prefer that it be printed in their font so that anyone trying to "duplicate" or "re-use" the article would have to have a license to use their font.

Instruments in music and vectors or brushes or inks/paints in graphical art are akin to fonts in that way.

To get a free open source Mona Lisa we would need to discover what brushes and paints were used, how, and in what sequence, to produce that painting.

We would then be free to see what the Mona Lisa would have looked like if it were performed using different brushes, different paints, different sequences.

-MarkM-

It depends if we are talking about music scores or music tracks.  For tracks it will take some time to listen, but that's potentially do-able.  For scores as you say it's impossible to judge the quality without listening to it being performed/recorded.  I'm not sure how scores can be accommodated.

No no no.

If you think that listening to the music takes a long time, imagine how long it will take to read the score and perform the music yourself to be able to judge its merit.
(because that's what markm is proposing)

That's the point I was trying to make. Maybe it did go under.

I don't know yet. I haven't made my mind up yet.

Is devcoin more about open source, or more about free content?

And when was the decision made, and by whom?

Often those two terms are used interchangeably although they represent different things.

Should devcoin strive for a balance between those two, especially when it comes to difficult (open source wise) content like music, or are we going to measure everything with the same yardstick?

When it comes to music, if you really want to be all open source about it, you would first need to create all the necessary open source music making tools, because the ones that are available at the moment are not considered at all by professional musicians. This should take a few years.

So if you were to go with the open source music making software that is available at the moment you might not attract the kind of musician you want.

Ofcourse the situation could change over time.

lol   Bravo on that insight. :p

But I know what you mean, they'll have to be admins to listen to the tracks, which will be time consuming.  At least until there are enough listeners who can rate the tracks in an automated way like imdb.  I would really enjoy rating music, and even giving feedback being primarily a musician myself.  This whole idea of devtome moving into music is really exciting, I have a bunch of tracks I'd love to put up on this.

Done:

static const char *strMainNetDNSSeed[][14] = {
   {"public.txn.co.in", "dvc.public.txn.co.in"},
   {"21stcenturymoneytalk.org", "dvc-seed.21stcenturymoneytalk.org"},
   {"devtome.com", "dvcstable01.devtome.com"},
   {"dvcnode.org", "dvcstable01.dvcnode.org"},
   {"dvcnode.org", "dvcstable02.dvcnode.org"},
   {"dvcnode.org", "dvcstable03.dvcnode.org"},
   {"dvcnode.org", "dvcstable04.dvcnode.org"},
   {"dvcnode.org", "dvcstable05.dvcnode.org"},
   {"dvcnode.org", "dvcstable06.dvcnode.org"),
   {"dvcnode.org", "dvcstable07.dvcnode.org"),
   {"dvcnode.com", "node01.dvcnode.com"},
   {"dvcnode.com", "node02.dvcnode.com"},
   {"dvcnode.com", "node03.dvcnode.com"},
    {NULL, NULL}
};

I assume you have dvcstable06 if you added it to dvcstable07. I went through the list based on old devcoin code and the seed nodes on devtome and added all of them into my dnsseeds structure above. This should give us maximum connections.

No problem. Especially for music created with a sequencer, it is easy to not only output a WAV file of the music (you can listen to) but also a MIDI-file that gives you information about what keys where pressed at what time and for how long. This should work easily for every MIDI-capable instrument.

I think it's important to understand that in contrast to pieces of text, music has to be listened to (meaning with your ears) to be able to review and judge its quality.
Much like you are using the appropriate sense (your eyes) to review and judge a piece of text, you should apply the appropriate sense when it comes to music.

Music has a psychological component to it that will simply not be existent in pure text or score form. Good luck reviewing that. That's why an acoustic representation of the work will let you much faster decide if the piece of music is decent or not.

Open Source is ultimately about performance, not the results that a particular performance results in.

So really what we want is not a recording of the output of a performance, such as a static image or a specific bit-sequence that represents a noise or sound, but, rather, the instructions necessary to perform that performance or produce some particular output/recording of a performance.

Open Source is all about performing, also known as executing.

So for a digitally painted painting someone painted with a paint program, what we should be wanting is the full recording of all the brush-strokes along with the code of all the brushes and so on.

Because our freedom given us by our free open source license should include the freedom to modify any of those brush-strokes or brushes, so we can see what that painting would look like if we moved our brush differently in a given moment of stroking a brush, or used a different brush or a different paint for certain of the brush-strokes, and so on.

Thus ultimately any static flat image or end-result-of-performance soundtrack is not really what we want for free open source at all, as that is simply a snapshot that does not include the source code, the instructions, the which brush or instrument to use and how to use it, that is the source code we need in order to duplicate / replicate / re-perform the thing.

-MarkM-

I don't think devcoin.org should ever strive to be more than an entry portal that informs and redirects people to all the different dedicated servers (with their specialized admin- and userfrontends, and forums)..

But those are just my 2 cents.

The plan was that we would use Open Transactions for the other-arts and other-sciences sites, so that we would allocate DeVCoins to those entire genres or sciences or arts then those individual projects would each be able to divvy up those DeVCoins themselves from their Open Transactions accounts or Open Transactions servers instead of trying to fit all the artists and scientists of all those arts and sciences all into the extremely limited 4000 blocks aka 4000 shares of the actual DeVCoin blockchain.

Ultimately maybe even Devtome would end up using Open Transactions too, since writing would be just one among many many arts and sciences so the entire art and/or science of writing would itself maybe only be getting one share or fraction of a share. (Once there are 4000 arts-and-sciences, the blockchain would only be sending out one share to each on the blockchain; the art and-or science of administration maybe included! This is why we need a huge market-cap!)

-MarkM-

Feel free to create any appropriate subdomain and point it to the ip of the dedicated server that will host the respective category of content.

I don't think that names will be a problem. But trying to put every different content style under one roof will be an impossibility.

That's why I am willing to create something outside of devtome.

Wouldn't it be better to merge the portal, devtome, devmusic, and devsound under one domain, if we're paying DVC over many mediums?

e.g. write.devcoin.org, music.devcoin.org, sound.devcoin.org, portal.devcoin.org, etc?

I don't think so, but phonic and graphic art gets very complicated because for example you often will find a single-layer image whose source is multiple layers, or a soundtrack whose source is at least partially various sound-bites or a library of various musical notes or sounds, yet they fail to release the underlying sources - the actual layers, the actual musical notes, the actual sound-bites - even though those underlying things that were composited together to form the image or soundtrack are from a programmer's perspective surely the "source material".

For example if a soundtrack is created by performing a number of actions such as "take that drum track over there, run it through this filter that you can download over there, layer on top of it that violin track over there" and so on, you end up with a bunch of such actions and components and arguments start about which parts are programmatic source code (the instructions about what to layer on top of what, which filter to use on which sound-bite before layering it and so on) and which parts are "content".

This is a crux of why programmatic source code (instructions as to how to go about doing something or logs of how something was done) licenses get to be hard to apply to various kinds of artwork.

Thus, it seems to me that for sound we should maybe consider starting out by funding the lowest level possible of the stuff, things like a free open source library of simulated musical instruments, a free open source library of sound-effects and so on.

Because what I have seen happen too often is kind of along the lines of either we get a file of bits, in some codex or format, that when played using a sound player of some kind comes out as some sound or song or symphony or whatnot, or we get a set of instructions (a musical score a musician would read while playing an instrument, for example: source code for execution by a musician who has such an instrument) telling us how to produce an instance of a piece provided we have access to certain instruments and sound-bites and musical notes and such but oops it turns out we do not in fact actually have such an instrument or such a sound-bite or such a musical note available in free open source form.

So I would like to start from the bottom-most layer for stuff we host ourselves.

For example for music we could have a point at which it is actually considered text/writing rather than actual music.

We could thus allow into Devtome (and I think we already do this) those aspects and parts of music that we can categorise as writing.

We could include under that heading the lyrics of lyrical pieces and the "scores" written in musical notation of frets and bars and quavers and semiquavers and so on.

Then when we do eventually get to the point of being ready to also start accepting recordings of actual performances of such pieces we would be in a position maybe to be very strict, much stricter than the wishy-washy arguments I have seen so many times in the past. We could insist that all the stuff used to perform the pieces must also be free open source, and first archive them before starting to accept recordings of performances of them or that use them.

For example suppose someone submits a score for a violin. I propose we accept that score as writing, it is a written set of instructions, thus in effect is it a program or programme instructing a musician how to produce a given piece given that they have access to a violin.

To my mind we should thus next ask where is the source code for a violin, and until we do have a free open source violin we should not proceed to accept recordings of performances of that piece since embedded in the code we have found this dependency upon a non free open source piece of code: the code for "violin".

So we'd want some form of "violin source code" in order that performances of the score using a violin could be open source performances, since one of the sources for the recording would be the violin that was used to play it, or at least some violin or other.

When you get to the actual recordings, some listeners might well be able to hear the differences between different instances of the general category of instruments known as "violin". Thus a recording of a piece played on a free open source violin might well be quite different than a recording of that same score executed upon a closed source violin. If the score was executed upon a closed source violin then to my mind the the recording is not open source, it is compiled code in which some of the stuff compiled into it is closed source.

Thus I would like our goal to be a free open source holodeck and 3d printer type of thing, in which each and every item and piece and performance is free open source, so that in your own holodeck at home or on your own planet's flagship or whatever you are free to freely replicate the instruments and objects used to create the sounds and all the brushes used to paint the paintings and all the inks used with the brushes and all the sound-filters and image-filters used and so on.

Basically if we do not have in free open source form all the details necessary for a holodeck to duplicate / replicate a thing then we do not have the sources for the thing thus the thing is not free open source.

Consider a scan of a printed document, for example, which was printed using a closed source font.

To me that scan is not free open source because we are not licensed to freely use that font to freely create/compose/compile such a scan ourselves from a text file of the words (aka lyrics?) and a script instructing us to use a certain font. We could produce a quite similar scan using a quite similar font, and that, in my opinion, is what should be done. We should tell the person submitting such a scan that they need to re-print it using a free open source font before we can accept it.

Similarly if someone plays a score upon a violin that is not free open source, we should tell them to go re-play it upon a free open source violin and submit to us the source of the violin along with the recording of the performance.

Since afterall the entire point of open source is the ability to replicate/duplicate/re-perform, and the entire point of free open source is that everyone is free not only to replicate/duplicate/re-perform but also to edit any of the components in order to produce similar or even very different end results using the same components.

For digital graphical art this should mean we get source code of all the brushes and filters and so on used so we can replicate the artist's performance if we are able to utilise those brushes and filters and so on in the same way that the artist did.

In cases where the artist used actual physical brushes to paint an actual physical painting for example, we unfortunately have a huge barrier ahead of us because we lack the source code of the physical universe (not to mention we lack the billions of years it would take to produce that specific paintbrush ab initio by executing a big bang and snipping out that brush from the resulting universe once our newly replicated universe reaches the point in its timeline at which its execution results in that brush).

But nonetheless that should be the ideal we are aiming at. We ideally want our Q-continuum buddies to have the full source code necessary for them to execute a universe just like ours, run it through from big bang to whatever lies ahead, and so on. We do not want patent or copyright trolls to come along and say that the Q, or the gods, or god the creator, or anyone else, is not permitted to create and/or execute a universe that happens to be indistinguishable from the universe that we live in right now nor the universe we will live in next week or did live in last week or next year or last year or next breath of Brahma or some previous breath of Brahma or next Kali-yuga nor next entire universe or some previous Kali-yuga or universe etc.

-MarkM-

Note: I am using this post as the initial sketch of a devtome article The ultimate in free open source.

Fair points. A few things. Everybody wants their articles to be most prominent and seems to have different ideas of what Devtome should be most focused on, so I try not to be too subjective (why it's alphabetical for instance). Shopping is under 'Home' on the front page and Companies within commerce, but your point still stands. I categorised Devtome with devcoin.org in mind (i.e. that devtome isn't just a sales pitch for devcoin and devcoin enterprises, the main portal should - now does - have that info). If consensus is otherwise it could be organised quite differently.

Inconsistencies - yep. The issue here is that devtome seemed to start in a way where everybody created articles with little consideration of future submissions. So probably most of my time is/has been spent filing, deleting and recreating 'categories' so that an article on say eggs can be categorised under [[category:Chicken]] rather than an exisitng =chicken article precluding any additions because it's actually an article on someone's page. There are a couple left like that but because they're comprehensive and/or fundamental like 'Devcoin' I've left them for the time being, but yes this does still raise problems for others trying to categorize. Keep the suggestions coming - maybe pm me with specific suggestions.