ChucK...is this useful?

[trimph1]

I'm thinking of using ChucK for a project here. I'd like to be able to write a routine that allow me to mangle the input from my guitar.

I'm curious as to whether anyone has done anything with this program and whether there might be another program for me to use....

[whyterabbyt]

I'm thinking of using ChucK for a project here. I'd like to be able to write a routine that allow me to mangle the input from my guitar.

I'm curious as to whether anyone has done anything with this program and whether there might be another program for me to use....

Looked at it, but not really done anything with it. Given that its aimed at live-coding, it should be fairly reliable in that context, and able to be tweaked on the fly. Probably better for realtime useage than other languages like CSound and Supercollider, although these days both of them can indeed do realtime...

[trimph1]

Is Supercollider supported? I'm going to have to check this out....

[whyterabbyt]

Is Supercollider supported? I'm going to have to check this out....

Yeah its still going.

http://supercollider.sourceforge.net/

Its been separated into a client-server architecture, so you can also do thinks like drive it from Processing now.

[rockstar_not]

I've signed up for a course on Coursera that uses ChucK as the language. I have one purpose for doing so, I'd like to be able to make an iPhone app that will allow me to send MSB and LSB patch changes out over USB to send program changes to my Zoom G5 guitar multi-fx pedal. I don't see where folks are compiling ChucK for iOS apps.

If it doesn't seem like this is a possibility, I think that I'm going to bail on the course.

For those interested in the ChucK class at Coursera, you might still have time to sign up: https://www.coursera.org/course/chuck101

[Caco]

I've used ChucK a lot in the past and found it to be a pretty nice language to use for audio. However, at the time I was using it (a few years back) I ran into a number of bugs which seemed like they would never be fixed as ChucK was essentially a dead project. I have no idea if things have improved since then though.

ChucK's big thing is that you can tweak the code in realtime for doing livecoding with. If this is not what you are looking to do then it may not be the right choice of language for you.

Personally, if you are looking at making at audio iphone app I'd strongly recommend Csound instead as it comes with an iOS SDK. Plus it is extremely CPU efficient for processing realtime audio, there is lots of documentation, books etc and a friendly community to help you out.

[whyterabbyt]

I've used ChucK a lot in the past and found it to be a pretty nice language to use for audio. However, at the time I was using it (a few years back) I ran into a number of bugs which seemed like they would never be fixed as ChucK was essentially a dead project. I have no idea if things have improved since then though.

ChucK's big thing is that you can tweak the code in realtime for doing livecoding with. If this is not what you are looking to do then it may not be the right choice of language for you.

Personally, if you are looking at making at audio iphone app I'd strongly recommend Csound instead as it comes with an iOS SDK. Plus it is extremely CPU efficient for processing realtime audio, there is lots of documentation, books etc and a friendly community to help you out.

And CSound6 seems to be heading in the livecoding direction too, from what I can see.

All we(*) need now is a 64-bit build of CSound6, and appropriate updates to the relevant bridges (the MAX csound~ object, Cabbage, that Usine one random some guy wrote...)

(*) for entirely self-serving definitions of 'we'

[Caco]

I've used ChucK a lot in the past and found it to be a pretty nice language to use for audio. However, at the time I was using it (a few years back) I ran into a number of bugs which seemed like they would never be fixed as ChucK was essentially a dead project. I have no idea if things have improved since then though.

ChucK's big thing is that you can tweak the code in realtime for doing livecoding with. If this is not what you are looking to do then it may not be the right choice of language for you.

Personally, if you are looking at making at audio iphone app I'd strongly recommend Csound instead as it comes with an iOS SDK. Plus it is extremely CPU efficient for processing realtime audio, there is lots of documentation, books etc and a friendly community to help you out.

And CSound6 seems to be heading in the livecoding direction too, from what I can see.

All we(*) need now is a 64-bit build of CSound6, and appropriate updates to the relevant bridges (the MAX csound~ object, Cabbage, that Usine one random some guy wrote...)

(*) for entirely self-serving definitions of 'we'

As that random guy who wrote the Usine one, I couldn't agree more

The livecoding stuff is a really exciting development but I just want the CSound API available as a 64-bit build!!

But when it eventually happens you can expect to see Csound available for Usine Hollyhock too.

[whyterabbyt]

I've used ChucK a lot in the past and found it to be a pretty nice language to use for audio. However, at the time I was using it (a few years back) I ran into a number of bugs which seemed like they would never be fixed as ChucK was essentially a dead project. I have no idea if things have improved since then though.

ChucK's big thing is that you can tweak the code in realtime for doing livecoding with. If this is not what you are looking to do then it may not be the right choice of language for you.

Personally, if you are looking at making at audio iphone app I'd strongly recommend Csound instead as it comes with an iOS SDK. Plus it is extremely CPU efficient for processing realtime audio, there is lots of documentation, books etc and a friendly community to help you out.

And CSound6 seems to be heading in the livecoding direction too, from what I can see.

All we(*) need now is a 64-bit build of CSound6, and appropriate updates to the relevant bridges (the MAX csound~ object, Cabbage, that Usine one random some guy wrote...)

(*) for entirely self-serving definitions of 'we'

As that random guy who wrote the Usine one

I knew that bit

The livecoding stuff is a really exciting development but I just want the CSound API available as a 64-bit build!!

But when it eventually happens you can expect to see Csound available for Usine Hollyhock too.

I was hoping you'd say that.

[Caco]

I've used ChucK a lot in the past and found it to be a pretty nice language to use for audio. However, at the time I was using it (a few years back) I ran into a number of bugs which seemed like they would never be fixed as ChucK was essentially a dead project. I have no idea if things have improved since then though.

ChucK's big thing is that you can tweak the code in realtime for doing livecoding with. If this is not what you are looking to do then it may not be the right choice of language for you.

Personally, if you are looking at making at audio iphone app I'd strongly recommend Csound instead as it comes with an iOS SDK. Plus it is extremely CPU efficient for processing realtime audio, there is lots of documentation, books etc and a friendly community to help you out.

And CSound6 seems to be heading in the livecoding direction too, from what I can see.

All we(*) need now is a 64-bit build of CSound6, and appropriate updates to the relevant bridges (the MAX csound~ object, Cabbage, that Usine one random some guy wrote...)

(*) for entirely self-serving definitions of 'we'

As that random guy who wrote the Usine one

I knew that bit

The livecoding stuff is a really exciting development but I just want the CSound API available as a 64-bit build!!

But when it eventually happens you can expect to see Csound available for Usine Hollyhock too.

I was hoping you'd say that.

The day a 64bit build comes out I will start coding!

I am quite frustrated by it as I use Csound a lot but sadly there still seems very little impetus for an x64 build from the development team

[whyterabbyt]

The day a 64bit build comes out I will start coding!

I am quite frustrated by it as I use Csound a lot but sadly there still seems very little impetus for an x64 build from the development team

I was quite suprised there wasnt an x64 build for CSound6, I would have thought it was a natural extension of the refaactoring they've done, especially given Richard Boulanger's involvement with the CSound4Live thing. I remember Michael Gogins posting a description of his Windows build setup for v5 a couple of years ago and it seemed quite involved, so unfortunately I doubt if doing a 'home' build to see if it'll work would be an easy option.
Guess iOS is too much the shiny distraction.

[Winstontaneous]

I've signed up for a course on Coursera that uses ChucK as the language. I have one purpose for doing so, I'd like to be able to make an iPhone app that will allow me to send MSB and LSB patch changes out over USB to send program changes to my Zoom G5 guitar multi-fx pedal. I don't see where folks are compiling ChucK for iOS apps.

You could also look in to libpd, which lets you embed the "vanilla" version of Pure Data (PD) in iOS and Android apps.

[rockstar_not]

I've signed up for a course on Coursera that uses ChucK as the language. I have one purpose for doing so, I'd like to be able to make an iPhone app that will allow me to send MSB and LSB patch changes out over USB to send program changes to my Zoom G5 guitar multi-fx pedal. I don't see where folks are compiling ChucK for iOS apps.

You could also look in to libpd, which lets you embed the "vanilla" version of Pure Data (PD) in iOS and Android apps.

That sent me down an interesting rabbit-hole! This is probably way over my head.

I'm just looking for a way to command bank and patch changes on my Zoom G5, which has an awful bank selection methodology (you have to simultaneously push two far-spaced foot buttons) and each bank holds only 3 patches.

I was hoping to write some simple app (but my object oriented programming experience is limited to VBA) to put a grid on the screen of the phone and in each box, simply send a pre-determined bank and program select message via MIDI to the Zoom G5.

One issue, the Zoom G5 has no published midi spec - though some users have sorted out at least the bank and program select stuff probably sniffing the USB stream

Another issue, I don't know if the iPhone can act as a USB host for the Zoom G5 as a peripheral.

Another issue, I don't know if there is proper cabling to go from iPhone 4s 30 pin connector to a USB B-type connector.

So perhaps it's just delusional of me to think that I could do this.

[Caco]

The day a 64bit build comes out I will start coding!

I am quite frustrated by it as I use Csound a lot but sadly there still seems very little impetus for an x64 build from the development team

I was quite suprised there wasnt an x64 build for CSound6, I would have thought it was a natural extension of the refaactoring they've done, especially given Richard Boulanger's involvement with the CSound4Live thing. I remember Michael Gogins posting a description of his Windows build setup for v5 a couple of years ago and it seemed quite involved, so unfortunately I doubt if doing a 'home' build to see if it'll work would be an easy option.
Guess iOS is too much the shiny distraction.

Yes, I was very surprised that x64 was not a key aspect of CSound6 but I'm not sure it's even on the roadmap at the moment. From the conversations I had it seemed that their thinking was x64 was unnecessary as the x86 build uses doubles internally and runs on x64 architecture.

But that is a rather shortsighted view to me though for software that includes an api as it effectively means you cannot embed the CSound library into an x64 application.

I'd looked at doing a 'home' build too and decided life was too short to go through CSound's lengthy build process

[Caco]

And especially for rockstar_not - here is a lengthy beginners tutorial explaining how to create a CSound / iOS app http://www-users.york.ac.uk/~adh2/iOS-C ... sGuide.pdf