<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The Beginning of the end. Pt 2</title>
	<atom:link href="http://www.djtechtools.com/2009/05/03/the-begining-of-the-end-pt-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.djtechtools.com/2009/05/03/the-begining-of-the-end-pt-2/</link>
	<description>A Complete Resource for Digital DJ Information and Technology</description>
	<lastBuildDate>Sun, 12 Feb 2012 11:39:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: aCiD/baSS</title>
		<link>http://www.djtechtools.com/2009/05/03/the-begining-of-the-end-pt-2/comment-page-1/#comment-41668</link>
		<dc:creator>aCiD/baSS</dc:creator>
		<pubDate>Mon, 20 Dec 2010 03:19:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.djtechtools.com/?p=1328#comment-41668</guid>
		<description>Also, why is Traktor just now getting a sampler!? and only with the S4!? come on NI, it&#039;s about time already, I&#039;m sick of using my Beatslicer to sample. I don&#039;t want to buy your $1000 controller just to sample! (even though it is a really really sexxxy piece of hardware).</description>
		<content:encoded><![CDATA[<p>Also, why is Traktor just now getting a sampler!? and only with the S4!? come on NI, it&#8217;s about time already, I&#8217;m sick of using my Beatslicer to sample. I don&#8217;t want to buy your $1000 controller just to sample! (even though it is a really really sexxxy piece of hardware).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: aCiD/baSS</title>
		<link>http://www.djtechtools.com/2009/05/03/the-begining-of-the-end-pt-2/comment-page-1/#comment-41667</link>
		<dc:creator>aCiD/baSS</dc:creator>
		<pubDate>Mon, 20 Dec 2010 03:14:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.djtechtools.com/?p=1328#comment-41667</guid>
		<description>Customization will ultimately win out. Sure, plenty of new users will want something that works out of the box, but if that were the only option, these companies would have a mutiny on their hands. I don&#039;t think there are any controllerists out there who don&#039;t customize their mapping. Your mapping determines your musical performance, or at leasts sets the boundaries of it. If we all used the same mapping, controllerists would loose a big piece of what makes us special and unique. I map almost as much as I mix, not because I want to, but because midi mapping is such a pain. I am not against replacing midi, so long as the alternative offers at least the same level of customization, and is at least a little easier (especially with LED&#039;s for crying out loud). Also, someone made a great point in saying that companies should provide decent prefab mappings. I mean its great that the buttons work and light up, but the user is totally overlooked. It&#039;s like they are mapping these controllers for people in Best Buy to play with...hmmm</description>
		<content:encoded><![CDATA[<p>Customization will ultimately win out. Sure, plenty of new users will want something that works out of the box, but if that were the only option, these companies would have a mutiny on their hands. I don&#8217;t think there are any controllerists out there who don&#8217;t customize their mapping. Your mapping determines your musical performance, or at leasts sets the boundaries of it. If we all used the same mapping, controllerists would loose a big piece of what makes us special and unique. I map almost as much as I mix, not because I want to, but because midi mapping is such a pain. I am not against replacing midi, so long as the alternative offers at least the same level of customization, and is at least a little easier (especially with LED&#8217;s for crying out loud). Also, someone made a great point in saying that companies should provide decent prefab mappings. I mean its great that the buttons work and light up, but the user is totally overlooked. It&#8217;s like they are mapping these controllers for people in Best Buy to play with&#8230;hmmm</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DjCarlao</title>
		<link>http://www.djtechtools.com/2009/05/03/the-begining-of-the-end-pt-2/comment-page-1/#comment-40252</link>
		<dc:creator>DjCarlao</dc:creator>
		<pubDate>Wed, 17 Nov 2010 20:55:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.djtechtools.com/?p=1328#comment-40252</guid>
		<description>Tambem acho e acredito,que nos temos de ter liberdade de trabalhar com o Sofware que mais nos agrade.
Sou totalmente a favor da liberdade de expressao.</description>
		<content:encoded><![CDATA[<p>Tambem acho e acredito,que nos temos de ter liberdade de trabalhar com o Sofware que mais nos agrade.<br />
Sou totalmente a favor da liberdade de expressao.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DjCarlao</title>
		<link>http://www.djtechtools.com/2009/05/03/the-begining-of-the-end-pt-2/comment-page-1/#comment-40250</link>
		<dc:creator>DjCarlao</dc:creator>
		<pubDate>Wed, 17 Nov 2010 20:52:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.djtechtools.com/?p=1328#comment-40250</guid>
		<description>Tambem acho e acredito,que nos de ter liberdade de trabalha com o Sofware que mais nos agrade.
Sou totalmente a favor da liberdade de expressao.</description>
		<content:encoded><![CDATA[<p>Tambem acho e acredito,que nos de ter liberdade de trabalha com o Sofware que mais nos agrade.<br />
Sou totalmente a favor da liberdade de expressao.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lukas</title>
		<link>http://www.djtechtools.com/2009/05/03/the-begining-of-the-end-pt-2/comment-page-1/#comment-18545</link>
		<dc:creator>Lukas</dc:creator>
		<pubDate>Mon, 25 May 2009 07:59:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.djtechtools.com/?p=1328#comment-18545</guid>
		<description>The sort of proprietary solution providers are not standing still here:
http://createdigitalmusic.com/2009/05/24/novation-automap-ableton-live-clip-control-coming-to-the-iphone/</description>
		<content:encoded><![CDATA[<p>The sort of proprietary solution providers are not standing still here:<br />
<a href="http://createdigitalmusic.com/2009/05/24/novation-automap-ableton-live-clip-control-coming-to-the-iphone/" rel="nofollow">http://createdigitalmusic.com/2009/05/24/novation-automap-ableton-live-clip-control-coming-to-the-iphone/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Agent Smith</title>
		<link>http://www.djtechtools.com/2009/05/03/the-begining-of-the-end-pt-2/comment-page-1/#comment-18020</link>
		<dc:creator>Agent Smith</dc:creator>
		<pubDate>Tue, 12 May 2009 15:21:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.djtechtools.com/?p=1328#comment-18020</guid>
		<description>Rufus definitely has the right idea.
The software should be designed to work with open standards and the controller should supply a standard set of drivers that can operate with any software with an additional layer that allows us to customise.
If some new DJ software release is launched I don&#039;t want to have to pay for a new controller in order to use this it and vice versa. It&#039;s definitely in the software and hardware manufacturers best interests to do this as well because their success won&#039;t be tied to another firm.
This problem is the same as any other software/protocol standards issue in its infancy like the Internet was back in the day. Eventually things will settle down, a standard will be adopted and you will be able to use controllers with different pieces of software, it&#039;s as certain as Betamax.</description>
		<content:encoded><![CDATA[<p>Rufus definitely has the right idea.</p>
<p>The software should be designed to work with open standards and the controller should supply a standard set of drivers that can operate with any software with an additional layer that allows us to customise.</p>
<p>If some new DJ software release is launched I don&#8217;t want to have to pay for a new controller in order to use this it and vice versa. It&#8217;s definitely in the software and hardware manufacturers best interests to do this as well because their success won&#8217;t be tied to another firm.</p>
<p>This problem is the same as any other software/protocol standards issue in its infancy like the Internet was back in the day. Eventually things will settle down, a standard will be adopted and you will be able to use controllers with different pieces of software, it&#8217;s as certain as Betamax.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RufusWhite</title>
		<link>http://www.djtechtools.com/2009/05/03/the-begining-of-the-end-pt-2/comment-page-1/#comment-18015</link>
		<dc:creator>RufusWhite</dc:creator>
		<pubDate>Tue, 12 May 2009 11:04:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.djtechtools.com/?p=1328#comment-18015</guid>
		<description>Personally, I think there might be room for another option here. People like HID because it works out of the box. People like Midi because it&#039;s customizable. What I&#039;d like to see is a protocol specifically targetted at DJ software that both hardware and software manufacturers adhered to (so things would work out of the box), but which was also extensible for future proofing and customizable by the end user.
There&#039;s a basic set of controls and feedback methods that exist in all DJ hardware/software solutions, and unless our paradigm of using decks and a mixer (whether real or virtual) changes dramatically in the foreseeable future, I think we&#039;ll be stuck with that paradigm for a while. Here&#039;s the basic set of controls we have and need across the board as DJs currently:
Deck controls: play/pause, cue, pitch bent, jog wheel, pitch, loop/cue controls etc.
Mixer controls: EQ, upfaders, gain, crossfader etc.
Browser controls: track select, track load, playlist select etc.
FX controls: FX select, paramater changes, wet/dry etc.
Output display: time remaining, stripe display, sticker position, track name, Vu meters, and button feedback.
So, what I&#039;m saying is that if we could have all controllers send/recieve standard messages for things like stop/start/cue/jog dial/pitch bend/track name display/sticker position display etc. etc. etc. so things worked out of the box with any software that supported those messages. Each unit (input method from the user, eg. crossfader or stop button or output from the computer eg. track name display) would have it&#039;s own unique ID, so that you could easily reconfigure each one to interact with the software differently from it&#039;s original factory settings if you so desired.
I have a feeling a lot of this can be done by OSC already (I don&#039;t know much about the protocol), but from what I&#039;ve heard OSC can become very complex for the end user setup point of view. Perhaps if manufacturers could agree on a standard set of OSC messages for the basic controls listed above, everyone would be more willing to accept it:
The software vendors would be much more willing to implement OSC if it meant not having to create a HID interpreter for each controller released onto the market, and know that controllers released in the future would work just as well with their software as ones currently already supported.
End users would feel much more confident about their purchases knowing that they can plug it straight into their computer and that it will work out of the box without having to go through hours/days getting a logically and intuitive setup working, but with the ability to customize individual elements as and when they see fit if need be.
Manufacturers can spend less on R&amp;D costs for proprietary protocols, whilst knowing that if they adhere to the standard, their hardware will work exactly as they intended regardless of the software being used with it.
Of course, all this is only taking into account what I see as the &#039;ideal&#039; situation - none of this takes into account inter-company politics and the fact that companies form partnerships and make their hardware only work properly with specific software intentionally (to retain a degree of exclusivity not achievable with other hardware/software combos). In the long run, I think this behavior is only hindering the progress of digital DJ technology - customers should be free to use any controller with any software and be confident that it will work as expected and without issue right out of the box, but allow a high degree of customization should the user want that also.
Fus</description>
		<content:encoded><![CDATA[<p>Personally, I think there might be room for another option here. People like HID because it works out of the box. People like Midi because it&#8217;s customizable. What I&#8217;d like to see is a protocol specifically targetted at DJ software that both hardware and software manufacturers adhered to (so things would work out of the box), but which was also extensible for future proofing and customizable by the end user. </p>
<p>There&#8217;s a basic set of controls and feedback methods that exist in all DJ hardware/software solutions, and unless our paradigm of using decks and a mixer (whether real or virtual) changes dramatically in the foreseeable future, I think we&#8217;ll be stuck with that paradigm for a while. Here&#8217;s the basic set of controls we have and need across the board as DJs currently:</p>
<p>Deck controls: play/pause, cue, pitch bent, jog wheel, pitch, loop/cue controls etc.<br />
Mixer controls: EQ, upfaders, gain, crossfader etc.<br />
Browser controls: track select, track load, playlist select etc.<br />
FX controls: FX select, paramater changes, wet/dry etc.<br />
Output display: time remaining, stripe display, sticker position, track name, Vu meters, and button feedback. </p>
<p>So, what I&#8217;m saying is that if we could have all controllers send/recieve standard messages for things like stop/start/cue/jog dial/pitch bend/track name display/sticker position display etc. etc. etc. so things worked out of the box with any software that supported those messages. Each unit (input method from the user, eg. crossfader or stop button or output from the computer eg. track name display) would have it&#8217;s own unique ID, so that you could easily reconfigure each one to interact with the software differently from it&#8217;s original factory settings if you so desired. </p>
<p>I have a feeling a lot of this can be done by OSC already (I don&#8217;t know much about the protocol), but from what I&#8217;ve heard OSC can become very complex for the end user setup point of view. Perhaps if manufacturers could agree on a standard set of OSC messages for the basic controls listed above, everyone would be more willing to accept it:</p>
<p>The software vendors would be much more willing to implement OSC if it meant not having to create a HID interpreter for each controller released onto the market, and know that controllers released in the future would work just as well with their software as ones currently already supported. </p>
<p>End users would feel much more confident about their purchases knowing that they can plug it straight into their computer and that it will work out of the box without having to go through hours/days getting a logically and intuitive setup working, but with the ability to customize individual elements as and when they see fit if need be. </p>
<p>Manufacturers can spend less on R&amp;D costs for proprietary protocols, whilst knowing that if they adhere to the standard, their hardware will work exactly as they intended regardless of the software being used with it. </p>
<p>Of course, all this is only taking into account what I see as the &#8216;ideal&#8217; situation &#8211; none of this takes into account inter-company politics and the fact that companies form partnerships and make their hardware only work properly with specific software intentionally (to retain a degree of exclusivity not achievable with other hardware/software combos). In the long run, I think this behavior is only hindering the progress of digital DJ technology &#8211; customers should be free to use any controller with any software and be confident that it will work as expected and without issue right out of the box, but allow a high degree of customization should the user want that also. </p>
<p>Fus</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DJ e Raleigh</title>
		<link>http://www.djtechtools.com/2009/05/03/the-begining-of-the-end-pt-2/comment-page-1/#comment-17920</link>
		<dc:creator>DJ e Raleigh</dc:creator>
		<pubDate>Sun, 10 May 2009 10:47:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.djtechtools.com/?p=1328#comment-17920</guid>
		<description>I&#039;ve been researching DJ controllers for weeks and have come down to two choices.  Either the Vestax VCI 300 because of the hi res jog wheels (it&#039;s pulse resolution is 4x higher than the VCi-100).  My other choice is Reloop&#039;s Digital Jockey 2 - Contraktor.
The Reloop controller is made to work with Traktor like Itch works with NS7 and VCI-300.  So, I&#039;m thinking for Traktor users looking for decent jog wheels, the Reloop Contraktor is the way to go.  Go with the VCI-300 if the midi setup doesnt bug you.  Before I make my purchase I&#039;d like to make sure that the Reloop jog wheels are on par with the Vestax variety if anyone knows that answer.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been researching DJ controllers for weeks and have come down to two choices.  Either the Vestax VCI 300 because of the hi res jog wheels (it&#8217;s pulse resolution is 4x higher than the VCi-100).  My other choice is Reloop&#8217;s Digital Jockey 2 &#8211; Contraktor.  </p>
<p>The Reloop controller is made to work with Traktor like Itch works with NS7 and VCI-300.  So, I&#8217;m thinking for Traktor users looking for decent jog wheels, the Reloop Contraktor is the way to go.  Go with the VCI-300 if the midi setup doesnt bug you.  Before I make my purchase I&#8217;d like to make sure that the Reloop jog wheels are on par with the Vestax variety if anyone knows that answer.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

