bitslide ?

  • Hello. I am asking where i could find these apps showed here :

    It's named bitslide in another video. But i didn't found anything on the forum about that.

    does anyone know where is it ?

    thank you

  • this needs to moved to the new wiki:

    also there must be a 64 version that uses /tilt floating around. i think this uses /adc which won't work on the 64. i'll look into it.

  • wow, that's what i was looking for, thanks. It works like a charm on my 40h kit. Do you know if it's hard to add a midi out version of this app ? (like midi life on the conway's game of life). I don't know anything about chuck/max programming, but would it be a good exercise to learn it ? But I don't know where to start. Maybe study the code using in midilife.

  • MidiLife runs in Max and just syphons off the /led messages being sent out of ChucK and assigns them MIDI notes. Probably not the best way to go about things, since ChucK is fully capable of handling MIDI all on its own. It's just that I will generally have Max running anyway. (I even went so far as to take the complete opposite track and write a life implementation inside of Max.)

    But. I would think that adding some MIDI-generating code to tiltmap would be a good exercise in learning some ChucK scripting. MidiLife won't really help in that regard, but there's got to be some good Chuck/MIDI tutorials out there on the net.

  • i'd start with the examples that come with the chuck download folder. there's a folder called /midi. there's also a section on midi in the tutorials chapter of the manual. i don't think it's that hard, but if you've never programmed at all before, it's maybe not that easy either. it might be a nice place to start though - if you want to learn, it's nice to have a clear, simple goal to work on.

    edit - ha bean beat me to it.

  • ok thanks, i'll try this. I'm a little bit afraid of chuck code but why not try when i have some time.

    btw, i saw a man on the forum who transformed the chuck code of to a max/msp 5 program called maxlife. Is it difficult to do that ? Or the code are not very similar ? Because I think max is more userfriendly than chuck to program on monome.

  • certain things are easier to do in a text based programming language like chuck - i.e. if you know how, you can use 10 lines of code and very quickly achieve what would take a lot of max patching. that said, max is easier in some ways because it's more visual, you can can see what's going on. that's just my opinion - i'm sure lots of proper programmers would disagree. i think the max-life implementation was just done to see if it was possible using only max. and it is, but it's not as "elegant" as using code.

    if you have jitter, there's a [jit.conway] object that implements life - i've never tried to interface that with the monome, but it'd probably be pretty easy. there don't seem to be many jitter users round these parts though. i have it, because it was included in the student upgrade to max5, i've just only used it for a few hours. i really should.

  • > btw, i saw a man on the forum who transformed the chuck code of to a max/msp 5 program called maxlife.

    Yeah, that was me. It's really nothing like the ChucK version. And even though Max is more generally immediately accessible because it's visual instead of text based, the maxlife patch is almost certainly more complicated to get into and make sense of than the ChucK life shred because text makes it simpler to do things like for-loops and manipulation of two dimensional arrays (which is basically what an implementation of life is all about).

    As far as text-based languages go, scripting languages (like ChucK, python, perl, ruby, &c) tend to be among the easiest to jump into and get a feel for, especially with a specific project goal in mind.

  • is there a 64 version?

  • it is a 64 version by default :]

  • what would be the prefix in monomeserial for the 64? thanks

  • @tehn - ported from old to new, I'll add a screen shot and the video later.

  • i tried the prefix /box...toggling buttons worked..but no tilt action..seems odd

    any word on a prefix?

  • It should be box...

    recv.event("/box/press, iii") @=> OscEvent inc_press;
    recv.event("/box/adc, if") @=> OscEvent inc_adc;

  • yeah..still no tilt action, i tried toggling ADC's on and off as well..

  • turn on the adc in monomeserial

    thanks jp

  • yeah thats what i tried...are there other adc's? im not familiar with chuck =\

  • Turn on two first adc's, and make sure any max/msp application and max/msp runtime isn't loaded.

    Then, run virtual machine and clic add!

  • yea i did all that..nada

    edit: btw, i noticed that once i click add, both the first 2 adc's turn on in monomeserial...but once again, just the lights turn on and no action from the accelerometer on the is it calibrated in chuck anyway?

  • ah, i think the wrong version is posted. try this. different prefix /tiltmap

  • appreciate the help tehn!

    seems to not be working either

    says it wont bind to port 8000...or any other port i change it to

  • ok it worked and tilted for a second, and then quit tilting lol

    sorry for pickin everyones brain! =\

  • sorry to keep dragging this, but its still not tilt action...any chuck users have a clue?

  • just got my 64 today and can't get anything going on this either.

  • you have to push buttons. And then it starts to tilts as when you move it

  • you've gotta also press 'add shred' to get anything coming out. This must be all done after the virtual machine has been turned on..

    Are you using mini audicle.

  • how can you no.1 record the sound off chuck.. I HATE SOUNDFLOWER!

  • It works for me now. I was using an outdated version of monome serial

  • so its the monome serial now? =\ basically i get the lights...but they don't tilt...thats it lol

  • make sure ADC ports are enabled in monomeserial, and max/msp runtime is closed

  • yeah those are on..nothing works

  • yeah i think you have a bad monome.

  • i've got this going, but one axis seems to be reversed:

    as the wiki page suggests, i have fiddled with the cable orientation, but that doesn't solve it, and i don't really fancy learning/editing the chuck code.

    is my accel upside down, maybe?


  • got the same problem on my 40h kit. Maybe i'll try to change the orientation of the accelerometer :)

  • so, i just opened it and rotate the acc on the bugged axe, and it works well now :)

  • what did you do to rotate it??

  • I originally fixed it with a double face scotch tape. I juste put some double face scotch tape on the other side, and turn it to make it work properly.

  • woah woah...whats goin on? lol that video doesnt work for me...i tried every diff cable orientation, but it still doesnt tilt

  • @bonanza: do you have a kit? if so, you can either swap the x/y wires, rotate the accel, or edit the code.

    there's a chance that the code is wrong, all around. i'll try to test it out later.

    @sim: are you using a 64 or a kit?

  • hey tehn, I'm using a 64

  • i have a series 64,

  • here's the file. try that out and see if it makes a difference.

  • lights work, but no it was before

  • maybe test your accelerometer with a multimeter, or resold each point.

  • @Alrick: im not using a kit, i have a 64

  • well, i've had a look inside, and it appears that the 64 accel is surface mount. so i don't really fancy having a go at flippin it!

    but, i'm having a go working on a purely max/msp version of monomeserial (like in base, with a few additions to accommodate for my own hardware). i've started implementing tilting, and having checked the operation of the accel with another user, it appears that my accel orientation is correct.

    must be the tiltmap app...?

  • i just tested the app..
    one axis is correct
    the other is inverted
    it seems like the zero (flat) point is incorrect. when on table. pixels move a bit.

    this can be customized in the app text i guess...
    but i got no time for that right now.
    max/msp is calling

  • i forgot to say im using a 64

  • greetings! i have a project coming up where i need tiltmap64 to run on the correct axis'... and as vinceent points out above, one axis is correct and the other is inverted- i tried to look into the code and see what needed changing but couldn't figure it out. is it a simple solution to fix this? thanks in advance for any ideas/solutions!

    p.s.- when the cable orientation is set to "left", the points of light run left to right correctly in regards to tilting the device, but run the opposite of the tilt on up and down movements