Kas, that's exactly what i was looking for!<br><br>Rob: I would be curious to look at that code if you don't mind dusting it off. Thanks! <br><br><br><div class="gmail_quote">2011/4/8 <span dir="ltr"><<a href="mailto:chuck-users-request@lists.cs.princeton.edu">chuck-users-request@lists.cs.princeton.edu</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Send chuck-users mailing list submissions to<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:chuck-users-request@lists.cs.princeton.edu">chuck-users-request@lists.cs.princeton.edu</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:chuck-users-owner@lists.cs.princeton.edu">chuck-users-owner@lists.cs.princeton.edu</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of chuck-users digest..."<br>
<br>Today's Topics:<br>
<br>
1. controlling individual chuck patches (Timothy Leonido)<br>
2. Re: controlling individual chuck patches (Robert Poor)<br>
3. Re: Hello and the state of ChucK question (Mark Cerqueira)<br>
4. Re: controlling individual chuck patches (Tomtom)<br>
5. Re: Hello and the state of ChucK question (Harald Gutsche)<br>
6. Re: controlling individual chuck patches (Kassen)<br>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Timothy Leonido <<a href="mailto:timothy.leonido@gmail.com">timothy.leonido@gmail.com</a>><br>To: <a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>
Date: Thu, 7 Apr 2011 19:50:32 -0400<br>Subject: [chuck-users] controlling individual chuck patches<br>hello, <div><br></div><div>could anyone offer advice on controlling individual chuck patches with an external device? currently my mode of operation is to add several shreds and control their parameters with maudi sliders (buf.rate, reverb, delay, gain), but i'd prefer to use an external controller. </div>
<div><br></div><div>i have an 8 channel alesis mixer with usb-- could this help to answer my question? please let me know if you have any controllers in mind, and also which section of the manual is best to read for making these connections. </div>
<div><br></div><div>thank you! </div><div><br></div><div>tim </div>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Robert Poor <<a href="mailto:rdpoor@gmail.com">rdpoor@gmail.com</a>><br>To: ChucK Users Mailing List <<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a>><br>
Date: Thu, 7 Apr 2011 18:23:48 -0700<br>Subject: Re: [chuck-users] controlling individual chuck patches<br>Hi Tim:<div><br></div>2011/4/7 Timothy Leonido <span dir="ltr"><<a href="mailto:timothy.leonido@gmail.com" target="_blank">timothy.leonido@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
could anyone offer advice on controlling individual chuck patches with an external device? </blockquote><div><br></div><div>For my performance setup, I created a ChucK patch controller class -- it received all incoming MIDI events and forwarded them to the current patch. Not surprisingly, it intercepted patch control events, and did a Machine.add() to launch a patch and make it current. It worked reliably for me. </div>
<div><br></div><div>Is that what you were looking for?</div><div><br></div><div>If you want more details, let me know -- I can dig up the code from the archives.</div><div><br></div><div>- Rob</div><div><br></div>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Mark Cerqueira <<a href="mailto:mark.cerqueira@gmail.com">mark.cerqueira@gmail.com</a>><br>To: ChucK Users Mailing List <<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a>><br>
Date: Thu, 7 Apr 2011 19:15:50 -0700<br>Subject: Re: [chuck-users] Hello and the state of ChucK question<br><div style="word-wrap: break-word;">I've never used Savannah, but from what I have used: +9001 git / github if you want to foster a "social coding" environment for the project in question...<div>
<br></div><div><div>mc</div><div><br><div><div>On Apr 7, 2011, at 1:32 AM, Kassen wrote:</div><br><blockquote type="cite"><br>Tom;<br><br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Savannah accounts are project based and need approval.</blockquote>
<div><br>I think the projects need approval and that we fall squarely in the category. <br></div></div></blockquote><div><br></div><div>As was said earlier, I also think Github's fork feature is great - people can fork off from the main ChucK branch, tinker around, and if they do something cool, they can request that it be merged back in. </div>
<div><br></div><div>I think that's all the control that's needed. People shouldn't need permission to mess around with ChucK or even need permission to request something be merged back into the master branch (this is assuming people don't go crazy and swamp Spencer with pull requests). If we make people bend-over backwards to contribute to a project, I can imagine they'd be less likely to contribute?</div>
<br><blockquote type="cite"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On github, anyone can<br>
create an account, fork the chuck repository and publish his work in plain<br>
sight.<br></blockquote><div><br>That's exactly what I'm doing; <a href="http://git.savannah.gnu.org/cgit/fluxus.git/log/?h=redacted" target="_blank">http://git.savannah.gnu.org/cgit/fluxus.git/log/?h=redacted</a><br>
I forked the Fluxus audio synth called Fluxa and added a lot of stuff to it.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I see that as a strong advantage as the community can experiment, leaving to<br>
the main branch maintainers the possibility to merge interesting propositions<br>
in a few simple commands.<br><br></blockquote><div><br>I agree. But I still don't see why Github is better than Savannah for projects like ours as it sounds about the same.<br></div></div></blockquote><div><br></div>
<div>If the only real main difference is needing approval to work on stuff, I'd say Github is the way to go. If that didn't convince you, consider that Tom Lieber also loves (loves, loves) Git...</div><br><blockquote type="cite">
<div class="gmail_quote"><div><br>Yours,<br>Kas.<br></div></div>
_______________________________________________<br>chuck-users mailing list<br><a href="mailto:chuck-users@lists.cs.princeton.edu" target="_blank">chuck-users@lists.cs.princeton.edu</a><br><a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
</blockquote></div><br></div></div></div><br><br>---------- Weitergeleitete Nachricht ----------<br>From: Tomtom <<a href="mailto:tomtom@herbesfolles.org">tomtom@herbesfolles.org</a>><br>To: chuck-users <<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a>><br>
Date: Fri, 08 Apr 2011 08:45:51 +0200<br>Subject: Re: [chuck-users] controlling individual chuck patches<br>Maybe you can use a MidiIn object for each of your shreds and pass some<br>
different CC numbers to each of them.<br>
<br>
tom<br>
<br>
Excerpts from Timothy Leonido's message of ven. avril 08 01:50:32 +0200 2011:<br>
> hello,<br>
><br>
> could anyone offer advice on controlling individual chuck patches with an<br>
> external device? currently my mode of operation is to add several shreds<br>
> and control their parameters with maudi sliders (buf.rate, reverb, delay,<br>
> gain), but i'd prefer to use an external controller.<br>
><br>
> i have an 8 channel alesis mixer with usb-- could this help to answer my<br>
> question? please let me know if you have any controllers in mind, and also<br>
> which section of the manual is best to read for making these connections.<br>
><br>
> thank you!<br>
><br>
> tim<br>
<br>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Harald Gutsche <<a href="mailto:hg42@gmx.net">hg42@gmx.net</a>><br>To: ChucK Users Mailing List <<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a>><br>
Date: Fri, 8 Apr 2011 08:54:55 +0200<br>Subject: Re: [chuck-users] Hello and the state of ChucK question<br>> people can fork off from the main ChucK branch, tinker around, and if they do<br>
> something cool, they can request that it be merged back in<br>
<br>
Having a simple central repo, everyone can work on any number of local<br>
forks of the project and work on them.<br>
Especially with git or mercurial it is very easy to have several<br>
branches around (in the same or in different working directories) and<br>
push/pull/merge between them.<br>
<br>
When something gets ready to be integrated in the main project, it can<br>
be send as patch to one of the main developers.<br>
This is where github (and now savannah?) adds a different workflow.<br>
First, the main developers can integrate patches themself, without the<br>
fork developer sending them.<br>
So it can be used as pull model instead of push model.<br>
<br>
But, on the other hand, as long as there is no request for<br>
integration, the changes in the fork accumulate.<br>
Integration of many changes at once can be very annoying, because<br>
there will be many conflicts in the merge process.<br>
<br>
If the fork developer tries to make a small patch for integration, he<br>
will try to make this easy, because he wants to convince the main<br>
developers.<br>
The main developers have to do the integration work.<br>
<br>
If the fork developer works on his own branch for a longer time, the<br>
fork can easily drift away from the main branch.<br>
But, if the fork developer regularly integrates changes from the main<br>
branch, he does the main integration work.<br>
<br>
One advantage of a system like github is the public fork repository.<br>
The fork also gets a community process, so the code is reviewed and<br>
tested and discussed by the community, before it makes it's way to the<br>
main branch. Even the main developers can add tips and solutions to<br>
the fork, also to make it better fitting to the main branch.<br>
<br>
So, at the end, all depends on the way people work together. Each<br>
model has it's advantages and disadvantages.<br>
I think a github like system should especially be used, if the fork is<br>
a bigger one, e.g. changing basic structures leading to changes in<br>
many files of the project.<br>
<br>
<br><br>---------- Weitergeleitete Nachricht ----------<br>From: Kassen <<a href="mailto:signal.automatique@gmail.com">signal.automatique@gmail.com</a>><br>To: ChucK Users Mailing List <<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a>><br>
Date: Fri, 8 Apr 2011 10:02:34 +0200<br>Subject: Re: [chuck-users] controlling individual chuck patches<br>Tim;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div>could anyone offer advice on controlling individual chuck patches with an external device? currently my mode of operation is to add several shreds and control their parameters with maudi sliders (buf.rate, reverb, delay, gain), but i'd prefer to use an external controller. </div>
<div><br></div><div>i have an 8 channel alesis mixer with usb-- could this help to answer my question? please let me know if you have any controllers in mind, and also which section of the manual is best to read for making these connections. </div>
<div><br></div><br></blockquote><div><br>Yes! And it's loads of fun.<br><br>These days are good ones for tinkering musicians; lots of interesting MIDI controllers are getting released and music games (which have nice controllers) have apparently gotten over their prime popularity-wise leaving many controllers to the bargains bin. <br>
<br>Go to your local second hand store or games shop bargain section. Find a interesting looking controller with a USB plug, if you find something especially exciting with a Playstation plug (or similar) find it a converter to USB. Essentially all game controllers with USB plugs will conform to the "HID" (Human Interface Device) standards, these should work everywhere without a need for extra drivers. You can get a MIDI one too, but those are most often more expensive and also less exciting (at least to me), they may come with nice leds that can blink though.<br>
<br>Plug it into your computer (on Windows you may now need to hit "ok" and "continue" a few times).<br><br>Open the folder in the /examples/ dir that deals with hid. These are quite clear. Use those to figure out what kind of data you can get out of it. If you found a MIDI controller instead use the MIDI folder, of course. <br>
<br>Write a file containing UGen definitions at the top, then a Shred that deals with the controller, then use the main shred to deal with generating sounds (for example keeping track of a sequence). Use extra shreds if you found multiple controllers. You can mix MIDI and HID ones if you like, one per shred. If needed borrow code from the HID example for the one shred, and code from examples that generate sound for the other. A good "mapping" between the controller and the sound will likely be more important than a complex sound, if in doubt; keep it simple. If in doubt; try to not use feedback on the computer screen.<br>
<br>Tweak this until it sounds good and seems expressive.<br><br>Practice.<br><br>Presto; within two days and 20 bucks you have a completely new instrument.<br><br>Optional; look for other musicians and test your new instrument by jamming with them.<br>
Optional; play gigs using this as soon as possible and make notes of what works well and what doesn't.<br>Optional; get addicted to finding cheap and unusual controllers, fill a cupboard with those.<br><br>Good luck!<br>
Kas.<br></div></div>
<br>_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
<br></blockquote></div><br>