electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
Live streaming at radio.electro-music.com

  host / artist show at your time
<on air> Various Artists ~ 2014 Autumnal Equinox ~ live streaming radio ~
Please visit the chat
 Forum index » DIY Hardware and Software » ChucK programming language
Creating Variables on-the-fly?
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [9 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
momo_the_monster



Joined: Apr 06, 2007
Posts: 5
Location: Los Angeles

PostPosted: Fri Apr 06, 2007 3:38 pm    Post subject: Creating Variables on-the-fly? Reply with quote  Mark this post and the followings unread

I'm writing code to toggle the (binary) state of buttonlights on a monome 40h, controllable by sending notes over my MIDI bus. I've attached my current code, it's pretty straightforward.

I set variable i to 0 (since our button starts 'off'). When a Midi Note is received, I run a function that checks the state of i - if it's 0, it should turn off the buttonlight (by sending the same MIDI note with a velocity of '0') and set i to 1 - it does the opposite if i is 1.

It works great until I add other buttons into the mix - because variable i is shared and does not always reflect the true state of the button I'm actually trying to affect.

Is there a way to dynamically generate a variable for each of these buttons? I've got a possible total of 64, and it seems like they should all have their own variable for holding state information. Thanks for any help you can give!


add_toggles.ck
 Description:

Download
 Filename:  add_toggles.ck
 Filesize:  578 Bytes
 Downloaded:  165 Time(s)

Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sat Apr 07, 2007 5:40 am    Post subject: Re: Creating Variables on-the-fly? Reply with quote  Mark this post and the followings unread

momo_the_monster wrote:

Is there a way to dynamically generate a variable for each of these buttons? I've got a possible total of 64, and it seems like they should all have their own variable for holding state information. Thanks for any help you can give!


Welcome!

Ok, let's dive right in.

You need 64 toggles that can each hold 1 or 0. We'll use integers to reflect those. We can make a row (we call it a array) of integres like this;

int button_toggles[64];

This defines 64 integers and sets them to 0 to start with. To toggle one (we'll name it "n") we'd use a function like this;

!button_toggles[n] => button_toggles[n];

what this does is that it looks up the state of the nth element, inverts it (logically) and writes the outcome back to that location.

If you'd like to represent those 64 toggles in a way more natural to the Monome you could make a matrix instead of a stright row like this;

int button_toggles[8][8];

That will create a 8x8 matrix. Indezing would now work with coordinates. Say we call our coordinates x and y (those will come from notenumber and MIDI channel as I understand the Monome).

!button_toggles[x][y] => button_toggles[x][y];

That's not quite "generating them on the fly" but it is nicely structured and there is no real need to generate those on the fly since we know ahead of time how many we will need.

if the binary toggle is hard to understand you can also use your own if-then construction which comes down to the same thing but this one is more compact and it does the exact same. You might want to look at the examples that cover arrays as well, they are quite simple to grasp and very usefull.


Hope that helped, do shout if you get stuck and keep on ChucKing!

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
kijjaz



Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4

PostPosted: Sat Apr 07, 2007 2:04 pm    Post subject: Reply with quote  Mark this post and the followings unread

i also have this one thing i wanna do:
being able to select a kind of oscillator to use before creating one.
(for example, a function that let the caller choose between SinOsc, TriOsc, .. etc)

i did something like this:
Code:
0 => int oscType;
if (oscType == 0) SinOsc s;
else TriOsc s;


but it says: [unnamed1]:line(2): 's' has already been defined in the same scope...

...
hey! ..

i'm sorry..
now i've got what i wanted with this:
Code:
0 => int oscSelect;
UGen s;

if (oscSelect == 0) new SinOsc @=> s;
else new TriOsc @=> s;


hahahahaha.... aaaa cool.

i tried this first:
Code:
0 => int oscSelect;
UGen s => dac;

if (oscSelect == 0) new SinOsc @=> s;
else new TriOsc @=> s;


but there was nothing going to the dac..
i guess it's because the old UGen s's address is connected to dac but not the new SinOsc s's address.

so this one generate sounds to dac:
Code:
0 => int oscSelect;
UGen s;

if (oscSelect == 0) new SinOsc @=> s;
else new TriOsc @=> s;

s => dac;


now i'm happy -_-"
it's my first time i can figure this thing out -_-"..
- - -

me such a newbie OOP programmer ^_^
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
moudi



Joined: Oct 07, 2006
Posts: 63
Location: Bern Switzerland

PostPosted: Sat Apr 07, 2007 2:22 pm    Post subject: Reply with quote  Mark this post and the followings unread

another possible solution with an array:
Code:
UGen u[2];
SinOsc s => u[0];
TriOsc t => u[1];

0 => int oscSelect;
u[oscSelect] => dac;

jassas
/moudi
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sat Apr 07, 2007 2:29 pm    Post subject: Reply with quote  Mark this post and the followings unread

Nice post! Good thinking and nice trick as well.
_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
momo_the_monster



Joined: Apr 06, 2007
Posts: 5
Location: Los Angeles

PostPosted: Sat Apr 07, 2007 3:11 pm    Post subject: Reply with quote  Mark this post and the followings unread

Excellent - thanks Kassen! Here's my original function:

fun void midi_toggle( int minote )
{
if (msg.data2==minote && msg.data3==127) {
minote => msg.data2;
if (i==0) { 127 => msg.data3; 1 => i; }
else { 0 => msg.data3; 0 => i; }
mout.send( msg );
}
}

I replaced the second if...else structure that tests for the state of the button with the bit you gave me - so now it looks like this:

fun void midi_toggle( int minote )
{
if (msg.data2==minote && msg.data3==127) {
minote => msg.data2;
!button_toggles[minote] => button_toggles[minote] => msg.data3;
mout.send( msg );
}
}

Of course I've previously declared button_toggles earlier with:
int button_toggles[64];

Thanks so much for the method! Like I said, this was my first try at programming in ChucK - I've felt the need to learn Max/MSP for a long time to build some interactive instruments that I haven't been able to do with Quartz Composer alone -- but I'm pretty sure I'll be able to use ChucK instead!

_________________
VJ Kung Fu :: Online Motion Magazine for DIY Video Artists
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Apr 08, 2007 8:04 am    Post subject: Reply with quote  Mark this post and the followings unread

momo_the_monster wrote:

I replaced the second if...else structure that tests for the state of the button with the bit you gave me - so now it looks like this:

fun void midi_toggle( int minote )
{
if (msg.data2==minote && msg.data3==127) {
minote => msg.data2;
!button_toggles[minote] => button_toggles[minote] => msg.data3;
mout.send( msg );
}
}

Of course I've previously declared button_toggles earlier with:
int button_toggles[64];


Very good, it's wonderfull to see people like you jump in, make rapid progress and within a very short time get a little working program. I hope those on the fence about starting but thinking it's all "hard" see this.

Still, I think it can be improved yet further. I think that this program of yours is going to grow and get more features, right? If so I'd try to keep functions like this as selfcontained as possible. If I remember tcorectly what was going the msg.data2 & msg.data3 come from a incoming note and you are here generating a outgoing one, right? I think I'd define a seperate message for MIDI output and make sure this function had everything it needs to format a outging message and send it to the port without depending on anything that's not in the function's arguments.

I recomend that because right now if you would add more functionality and perhaps more things foing on at the same time you risk breaking this function by changing something else. For larger programs, once they don't fit entirely on the schreen and in your head anymore that's a realy big deal.

In the future you might want a single button press to do what it does now plus -say- aditional blinking of lights or similar changes. Once you get into that sort of thing it becomes harder to do things like use msg.data3 as a variable itself and more important to keep it modular and extendable.

If you start now structuring your program with further extendability in mind things will be easier later with less unpleasant surprises.

In practice here I'd move the parsing of the incoming message out of this function and call "midi_toggle" depending on what came in. The advantage there is that you might later want to have more functions that do different things and the bit of your program that parses incoming messages could simply be extended to also call other functions when other mesages arrive while you will be secure in knowing that "midi_toggle" will keep working.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
momo_the_monster



Joined: Apr 06, 2007
Posts: 5
Location: Los Angeles

PostPosted: Sun Apr 08, 2007 11:24 am    Post subject: Reply with quote  Mark this post and the followings unread

Thanks for the suggestions - I wrote this program as a stopgap measure to provide me some needed functionality for the Monome 40h. The next iteration of official Monome programs should make this patch redundant, so I'm not planning to develop it further.

However, I am planning on creating a Simon-like call-and-repeat game using the Monome, and I'll certainly put your suggestions to use when I start up that project.

Thanks again!

_________________
VJ Kung Fu :: Online Motion Magazine for DIY Video Artists
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Apr 08, 2007 4:59 pm    Post subject: Reply with quote  Mark this post and the followings unread

There's no need at all to defend this code; It's most definately not under attack. I myself make quick&dirty setups like that to test and prove concepts or to quickly get some temporary functionality all the time. It's very ChucKian.

You're doing great, looking forward to hearing about your game!

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [9 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » ChucK programming language
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
e-m mkii

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use