[chuck-users] chuck-users Digest, Vol 69, Issue 10

Fri Apr 8 13:42:49 EDT 2011

Kas, that's exactly what i was looking for!

Rob: I would be curious to look at that code if you don't mind dusting it
off.  Thanks!

2011/4/8 <chuck-users-request at lists.cs.princeton.edu>

> Send chuck-users mailing list submissions to
>        chuck-users at lists.cs.princeton.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> or, via email, send a message with subject or body 'help' to
>        chuck-users-request at lists.cs.princeton.edu
>
> You can reach the person managing the list at
>        chuck-users-owner at lists.cs.princeton.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of chuck-users digest..."
>
> Today's Topics:
>
>   1. controlling individual chuck patches (Timothy Leonido)
>   2. Re: controlling individual chuck patches (Robert Poor)
>   3. Re: Hello and the state of ChucK question (Mark Cerqueira)
>   4. Re: controlling individual chuck patches (Tomtom)
>   5. Re: Hello and the state of ChucK question (Harald Gutsche)
>   6. Re: controlling individual chuck patches (Kassen)
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Timothy Leonido <timothy.leonido at gmail.com>
> To: chuck-users at lists.cs.princeton.edu
> Date: Thu, 7 Apr 2011 19:50:32 -0400
> Subject: [chuck-users] controlling individual chuck patches
> hello,
>
> 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.
>
> 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.
>
> thank you!
>
> tim
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Robert Poor <rdpoor at gmail.com>
> To: ChucK Users Mailing List <chuck-users at lists.cs.princeton.edu>
> Date: Thu, 7 Apr 2011 18:23:48 -0700
> Subject: Re: [chuck-users] controlling individual chuck patches
> Hi Tim:
>
> 2011/4/7 Timothy Leonido <timothy.leonido at gmail.com>
>
>> could anyone offer advice on controlling individual chuck patches with an
>> external device?
>
>
> 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.
>
> Is that what you were looking for?
>
> If you want more details, let me know -- I can dig up the code from the
> archives.
>
> - Rob
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Mark Cerqueira <mark.cerqueira at gmail.com>
> To: ChucK Users Mailing List <chuck-users at lists.cs.princeton.edu>
> Date: Thu, 7 Apr 2011 19:15:50 -0700
> Subject: Re: [chuck-users] Hello and the state of ChucK question
> 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...
>
> mc
>
> On Apr 7, 2011, at 1:32 AM, Kassen wrote:
>
>
> Tom;
>
> Savannah accounts are project based and need approval.
>
>
> I think the projects need approval and that we fall squarely in the
> category.
>
>
> 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.
>
> 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?
>
>
>
>> On github, anyone can
>> create an account, fork the chuck repository and publish his work in plain
>> sight.
>>
>
> That's exactly what I'm doing;
> http://git.savannah.gnu.org/cgit/fluxus.git/log/?h=redacted
> I forked the Fluxus audio synth called Fluxa and added a lot of stuff to
> it.
>
>
>>
>> I see that as a strong advantage as the community can experiment, leaving
>> to
>> the main branch maintainers the possibility to merge interesting
>> propositions
>> in a few simple commands.
>>
>>
> I agree. But I still don't see why Github is better than Savannah for
> projects like ours as it sounds about the same.
>
>
> 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...
>
>
> Yours,
> Kas.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Tomtom <tomtom at herbesfolles.org>
> To: chuck-users <chuck-users at lists.cs.princeton.edu>
> Date: Fri, 08 Apr 2011 08:45:51 +0200
> Subject: Re: [chuck-users] controlling individual chuck patches
> Maybe you can use a MidiIn object for each of your shreds and pass some
> different CC numbers to each of them.
>
> tom
>
> Excerpts from Timothy Leonido's message of ven. avril 08 01:50:32 +0200
> 2011:
> > hello,
> >
> > 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.
> >
> > 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.
> >
> > thank you!
> >
> > tim
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Harald Gutsche <hg42 at gmx.net>
> To: ChucK Users Mailing List <chuck-users at lists.cs.princeton.edu>
> Date: Fri, 8 Apr 2011 08:54:55 +0200
> Subject: Re: [chuck-users] Hello and the state of ChucK question
> > 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
>
> Having a simple central repo, everyone can work on any number of local
> forks of the project and work on them.
> Especially with git or mercurial it is very easy to have several
> branches around (in the same or in different working directories) and
> push/pull/merge between them.
>
> When something gets ready to be integrated in the main project, it can
> be send as patch to one of the main developers.
> This is where github (and now savannah?) adds a different workflow.
> First, the main developers can integrate patches themself, without the
> fork developer sending them.
> So it can be used as pull model instead of push model.
>
> But, on the other hand, as long as there is no request for
> integration, the changes in the fork accumulate.
> Integration of many changes at once can be very annoying, because
> there will be many conflicts in the merge process.
>
> If the fork developer tries to make a small patch for integration, he
> will try to make this easy, because he wants to convince the main
> developers.
> The main developers have to do the integration work.
>
> If the fork developer works on his own branch for a longer time, the
> fork can easily drift away from the main branch.
> But, if the fork developer regularly integrates changes from the main
> branch, he does the main integration work.
>
> One advantage of a system like github is the public fork repository.
> The fork also gets a community process, so the code is reviewed and
> tested and discussed by the community, before it makes it's way to the
> main branch. Even the main developers can add tips and solutions to
> the fork, also to make it better fitting to the main branch.
>
> So, at the end, all depends on the way people work together. Each
> model has it's advantages and disadvantages.
> I think a github like system should especially be used, if the fork is
> a bigger one, e.g. changing basic structures leading to changes in
> many files of the project.
>
>
>
> ---------- Weitergeleitete Nachricht ----------
> From: Kassen <signal.automatique at gmail.com>
> To: ChucK Users Mailing List <chuck-users at lists.cs.princeton.edu>
> Date: Fri, 8 Apr 2011 10:02:34 +0200
> Subject: Re: [chuck-users] controlling individual chuck patches
> Tim;
>
>
>> 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.
>>
>> 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.
>>
>>
>>
> Yes! And it's loads of fun.
>
> 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.
>
> 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.
>
> Plug it into your computer (on Windows you may now need to hit "ok" and
> "continue" a few times).
>
> 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.
>
> 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.
>
> Tweak this until it sounds good and seems expressive.
>
> Practice.
>
> Presto; within two days and 20 bucks you have a completely new instrument.
>
> Optional; look for other musicians and test your new instrument by jamming
> with them.
> Optional; play gigs using this as soon as possible and make notes of what
> works well and what doesn't.
> Optional; get addicted to finding cheap and unusual controllers, fill a
> cupboard with those.
>
> Good luck!
> Kas.
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20110408/fb3fd185/attachment-0001.html>