Networked Tracking :d

[choice]

i saw this and immediatly thought of this thread:

Each download is aware of one tracker URL. Using DNS, the tracker hostname can be given multiple IP addresses (many A records). When a peer tries to contact the tracker, it will randomly use one of these IP addresses.

The minder acts as a tracker for the trackers. Using SSL, tracker peer lists are distributed to each tracker, who can then contact other trackers to keep “the peer list” up-to-date.

its ironic.
this could be the base idea of data flow for announcing your presence upon the network, and the patterns, instruments.

one would log in, announce itself, then begin recieving a packed rns made up of a master patterns list, instruments and peer data.
(each entity on the network would generate small pieces to transmit to the new entity. possibly decreasing alot of lag)

then begin constantly asking for new instructions. an update as needed.
transmission of new pattern an instrment data could be triggered by an inject command. or if you have a good machine/connection there could be a polling function.

eventually an ethic would declare itself among the seasoned users an everyone would go by a certain standard, if not then give the ability to kick!

[mindplay]

@taktik

I always asked myself how this worked in detail. Samples where not transfered, right? What happened then if someone loaded a sample or instrument?

taktik,

I know this is no small feature to implement, but I continue to have hope!

This is a feature I’ve been waiting to see in a modern music program for at least five years.

For me, this would be the feature that would revive music making!

…

One thought … your new XML import/export, would it work with partial documents as well? If so, perhaps this could be exploited to implement this feature … you would then have a standardized way to transfer anything from samples to patterns, instrument data, anything that can be saved/loaded in XML format at the moment.

Basically, the remaining workload then consists of coming up with a good “protocol” - how the trackers “talk” to each other, what happens if two users try to allocate the same sample or instrument slot, etc. Probably, a “server” would have to be implemented - one of the trackers in a session would have to act as server, and the rest as clients. The server would be responsible for locking, and clients would have to explicitly lock an instrument or sample slot before making any changes. This would have to be reflected in the GUI too, of course…

I guess implementing something like this would be a pretty big job.

But I think the internet, in most developed countries, at this point, is ready for it - it’s fast enough nowadays to support sample transfer, etc.

I know it probably won’t happen, but I hope you’ll at least consider the idea again…