Jump to content

protofuse

Programmer
  • Posts

    288
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by protofuse

  1. que ce soit en anglais, en français ou autre, les membres du forum n'aiment pas trop quand des questions sont posées alors que l'on peut aisément trouver les réponses.

    je l'ai appris en commençant mon projet et en postant ici.

    ceci dit, tu ne pourras pas passer à côté des liens suivants:

    - http://www.midibox.org/dokuwiki/doku.php?id=application_development et si tu es sous l'OS windows: http://www.midibox.org/dokuwiki/doku.php?id=windows_toolchain_core (installer l'ensemble de la chaines pour compiler tes sources)

    - il te faudra cela: http://miosstudio.midibox.org/ pour que ton code compilé soit uploadé via midi sysex dans ton core

    - http://www.midibox.org/dokuwiki/doku.php?id=mios

    la solution ne tombera pas du ciel, ne l'attends pas

    procède étape par étape

    comprends comment fonctionne le MIOS

    apprends à le modifier, le compiler, et l'uploader dans ta box

    etc

  2. if anybody on the forum is using liveapi (i know there's a few), i've started a new google group for us to share information. the old one seems to have died, and is filling up with spam.

    http://groups.google...ableton-liveapi

    let's keep this alive! i am still using liveapi and have learned so much about it. i think we can support each other very well.

    ultra

    hello ultra.

    I'm using it and used it for a while

    with max for live, Live Object Model is officially published.

    with noofny, we also tested pure python script with the new Live Object Model and it works fine without max for live.

    you may be interested.

    all the best,

  3. tres beau travail en effet,c'est super propre. :blink:

    Pour ma part,au point de vue patience,je ne crois pas avoir été vite au point de bruler les etapes (cela fait maintenant 14 mois que j'ai demarré ce projet)

    je me suis longuement documenté avant de commencer car je n'avais aucune experience de l'electronique,ou meme de la soudure.

    Petit a petit,j'ai tout de meme reussi a comprendre comment tout ce petit monde se connetait,puis et arrivé l'instant fatidique de charger le bootstrap,le mios et l'application,cela ne s'est pas fait sans mal...(CF les topics crées sous mon ancien pseudo)

    Le principe meme de devoir ecrire dans le code source m'est pour le momment insurmontable qui plus est avec des posts sur le sujet ecris dans un anglais que je ne maitrise pas.

    Je dois bien admettre que je suis zero en prog et malheureusement,pour toutes ces raisons,la passion du debut fait place maintenant a de la frustration .

    Je ne desespere pourtant pas.....

    En gros,ma requete serait que l'on m'explique de façon "simple" comment faire ces changements dans le mios.

    En tout cas merci d'avoir pris la peine de me repondre,j'ai conscience d'etre un enorme boulet....

    Encore bravo pour ton projet,ça laisse reveur. :twitch:

    si tu es sur un chat (msn, gmail ou autre), je te propose de répondre à tes questions.

    c'est plus rapide, surtout pour moi.

  4. merci pour tes conseils mais je comprend difficilement l'anglais technique

    je suis peut etre passé tot pres de l'explication qu'il me faud sur le wiki ....

    cela repond tres certainement a ma question a propos d'un eventuel tuto en "français " en gros,c'est le system D comme D.....e toi.

    en somme,il ne me reste plus qu'a oublier la possibilité d'un midibox lc avec 24 faders.....

    merci quand meme

    je suis parti de ZERO et j'ai conçu ça:

    http://www.julienbayle.net/diy/protodeck/

    ... mais ça m'a demandé un minimum d'effort pour rentrer dans le truc ; ça m'a demandé du temps aussi

    il te faut un peu de courage et de la patience et tu pourras faire tout ce que tu veux.

    le framework midibox est TRES performant et complet

    faut pas lacher le truc!

  5. bon,la c'est la catastrophe.

    il me semblait avoir pigé mais en fait,j'y comprend rien.......

    deja,ou se trouve ce fameux fichier "init"?

    avec quoi faut il le modifier,quel programme?

    est ce avec pearl ?,car si c'est le cas je pige rien avec....

    je recherche sur le forum et sur ucapps tout ce qui pourrait m'aider a comprendre,mais plus je cherche,moins je trouve et surtout rien ne fait tilt dans ma pauvre cervelle.

    Je suis vraiment un gros naze pour ce qui est programmation ;

    n'existe t'il pas un tuto clair et precis sur ce sujet pour les newbies comme moi ?

    en bref: Aidez moi s'il vous plait.......

    merci d'avance

    il existe beaucoup de tutoriels.

    vues tes questions, je pense qu'il faut que tu commences par lire les docs du wiki.

    tout est en anglais.

    je te conseilles aussi les forums en anglais.

    il y a bcp de gens expérimentés aussi

  6. :frantics: bonjour a tous

    Depuis le changement de look du site,il m'est impossible de me connecter avec le pseudo "djahan" :unsure:

    Pour faire court,je suis sur la fabrication d'une midibox LC avec "24 faders"(3 cores)

    pour l'instant,seuls 8 pistes fonctionnent pas trop mal (sauf petit probleme de ledmeter sous cubase sx3)

    La seconde tranche de 8 faders etant en construction,je me pose la question de savoir comment activer le midibox link afin de configurer mes 2 premiers cores en MIDIbox Link Forwarding et le dernier en MIDIbox Link Endpoint.

    J'ai beau lire et relire tout ce que je trouve sur le sujet,cela reste floue,voir carrement etre du chinois :ahappy:

    Je vous remercie par avance de votre aide.

    PS :sous mon ancien pseudo j'avais promis de montrer l'avancement de ma box ,seulement la,je vois pas non plus comment poster des photos.

    quiche-man a encore frappé :frantics:

    le concept midilink est là : http://www.ucapps.de/midibox_link_fr.html

    pour l' "activer" comme tu dis, il faut mettre dans Init():

    pour le premier core (premier dans le sens du flux midi entrant dans ta midibox)

    MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_FP);
    pour le second core
    MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_EP);

    tu as l'équivalent en assembleur là: http://www.ucapps.de/mios8_fun.html#MIOS_MIDI_MergerSet

  7. Why are you not doing this?

    Best Regards, Thorsten.

    first,I was/am afraid about most unfriendly parsing (unfriendly only in the design step.. indeed)

    second, I have some doubt about midi notes treatments:

    I have 2 core, on each one, a DOUT and DIN.

    so, DINs have to send midi note ONLY to the midi output (from the midibox point of view)

    and DOUTs have to receive midi note ONLY from the midi input.

    probably I can do that by using if() statements in MPROC_NotifyReceivedEvnt()

    I'll do that today (day off in france! yeah!)

    fyi, this mapping is targeted for be used in max for live (the max/msp software hosted in Ableton Live)

  8. hello experts,

    I have:

    - 87 pots (sending CC values)

    - 82 buttons (sending midi note on & off)

    - 86 RGB leds (receiving midi note on message to be light or not (8 states including off))

    thus for my mapping, I need:

    87 CC + (82 + 86) Notes

    right?

    how could I use only one midi channel to do that ?

    this constraint exists in my DAW.

    I could make a different treatment for note to midi in, and note to midi out.

    in that case, as 1 channel = 127 CC + 127 Notes, it would be enough!

    ideas? way?

  9. this code doesn't give me any warning :smile: :

    /////////////////////////////////////////////////////////////////////////////
    
    // This function is called by MIOS when a complete MIDI event has been received
    
    /////////////////////////////////////////////////////////////////////////////
    
    void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
    
    {
    
    	if( (evnt0 & 0xf0) == 0x90)			// being sure that this is a note message
    
    	{
    
    		unsigned char channelIndex = evnt0-0x90;
    
    		unsigned char noteIndex = evnt1;
    
    		unsigned char value = evnt2;
    
    		unsigned char matrixIndex = ( (noteIndex - 1 + _NOTE_MATRIX_OFFSET)+channelIndex );
    
    
    		if (matrixIndex > 0 && matrixIndex < 64)			// being sure that we'll write inside bounds
    
    		{
    
    				matrix[matrixIndex] = value;
    
    		}
    
    	}
    
    }

    Thorsten, the 8* was to manage my leds like that:

    - one midi channel per column

    - one note pitch per line

    - velocity gives the color

    but it needs to be improved and finished.

    btw, now, I can write at last : EVERYthing works fine here!

    and, the most important, I understood why the different things that gave me headache didn't work in the past !!!

    thanks to all of you (I already do that on my website )

  10. the compilation of this code gives me warning 94: comparison is always true due to limited range of data type for the second if() statement.

    
    void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
    
    {
    
    	if( (evnt0 & 0xf0) == 0x90)			 	// being sure that this is a note message
    
    	{
    
    	unsigned char channelIndex = evnt0-0x90;
    
    	unsigned char noteIndex = evnt1;
    
    	unsigned char value = evnt2;
    
    	unsigned char matrixIndex = noteIndex - 1 - _NOTE_MATRIX_OFFSET + channelIndex;
    
    
    		if (matrixIndex >= 0 && matrixIndex < 32)	// being sure that we'll write inside bounds
    
    		{
    
    			matrix[matrixIndex] = value;
    
    		}
    
    	}
    
    }
    same warning if I cast like that :
    void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
    
    {
    
    	if( (evnt0 & 0xf0) == 0x90)					// being sure that this is a note message
    
    	{
    
    	unsigned char channelIndex = evnt0-0x90;
    
    	unsigned char noteIndex = evnt1;
    
    	unsigned char value = evnt2;
    
    	unsigned int matrixIndex = (int) ( noteIndex - 1 - _NOTE_MATRIX_OFFSET + channelIndex );
    
    
    		if (matrixIndex >= 0 && matrixIndex < 32)// being sure that we'll write inside bounds
    
    		{
    
    			matrix[matrixIndex] = value;
    
    		}
    
    	}
    
    }

    any suggestions?

  11. I don't think that it will compile this way (there is a missing bracket)

    Why are you checking for <= 64?

    I would expect a check for < 32, since matrix[] is in the range 0..31

    And why do you multiply by *8?

    There are 16 channels... somehow I'm missing a clear concept.

    It makes sense to add a comment what actually the function should do, and what are the constraints.

    This would make it easier for others to find out what's wrong in the code.

    Or it could even help you to find the error by yourself ;)

    Best Regards, Thorsten.

    yes, I corrected that...

    for the midi note / led mapping, I had to redo little things.

    the second test about the matrixIndex gives me a warning:

    warning 94: comparison is always true due to limited range of data type

    grrr.

    explicit cast is required?

  12. It's better to calculate "8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex" only a single time, and to put the result into a temporary variable.

    Btw.: you forgot the 8* multiplication inside if()

    Best Regards, Thorsten.

    indeed, ok!

    void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
    
    {
    
    	if( (evnt0 & 0xf0) == 0x90)					// being sure that this is a note message
    
    	{
    
    	unsigned char channelIndex = evnt0-0x90;
    
    	unsigned char noteIndex = evnt1;
    
    	unsigned char value = evnt2;
    
    	unsigned char matrixIndex = noteIndex - 1 - _NOTE_MATRIX_OFFSET + channelIndex;
    
    
    		if (matrixIndex >= 0 & matrixIndex <= 64)// being sure that we'll write inside bounds
    
    		{
    
    			matrix[matrixIndex] = value;
    
    		}
    
    	}
    
    }

    I'll fire it in the gear!

  13. void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
    
    {
    
    	if( (evnt0 & 0xf0) == 0x90)
    
    	{
    
    	unsigned char channelIndex = evnt0-0x90;
    
    	unsigned char noteIndex = evnt1;
    
    	unsigned char value = evnt2;
    
    
    		if( (noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex <= 64)
    
    		{
    
    			matrix[8*(noteIndex - 1 - _NOTE_MATRIX_OFFSET)+channelIndex] = value;
    
    		}
    
    	}
    
    }

    the first if is ok, the second one could be improved I guess (bitwise operator ?!)

  14. Er... what are you doing in MPROC_NotifyReceivedEvnt() of the second core?

    
    void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
    
    {
    
    	int channelIndex = evnt0-0x90;
    
    	int noteIndex = evnt1;
    
    	unsigned char value = evnt2;
    
    	matrix[8*(noteIndex - 1 + _NOTE_MATRIX_OFFSET)+channelIndex] = value; //-1 cause note begin at 1 and row at 0
    
    }
    
    

    this function will write into a RAM location depending on the received event.

    There is no if() branch which filters the expected events, accordingly any received event will write something into the matrix[] array.

    Let's assume 0xba 0x02 is received:

    channelIndex = 0xba-0x90 = 0x2a (instead of 0xa --- hint: it's better to write "unsigned char channelIndex = evnt0 & 0xf")

    noteIndex = 0x2

    -> matrix[8*(0x2a-1+_NOTE_MATRIX_OFFSET)+0x2a] = value

    Thats somewhere outside the array range.. Something random will happen (*) after this write operation. The effect will change whenever you add new/remove old code.

    So, I strongly recomment you to check for the received event -> if( (evnt0 & 0xf0) == 0x90 )

    and to add some additional checks to ensure that matrix[] is never written outside the declared range.

    It's also better to use "unsigned char" (8 bit values) instead of "int" (16 bit values) for faster code execution.

    The same programming error exists in MPROC_NotifyReceivedEvnt() of the first core.

    Best Regards, Thorsten.

    (*) this could also explain similar "strange effects" that you noticed in the past.

    Thorsten, I'll correct it right now and test it ... just "after right now"

    it is strange that only 1 pot does that...

    thanks a lot ! I keep you informed !!

  15. OK, it seems T.K. nailed the 0xBA, 0x02 bug..

    0xBA = Status Byte, Control Change, Channel 11

    0x02 = Breath Controller (Coarse)

    0x?? = Data Value for Breath Control..

    So, it's looking for another byte of data there..

    I have said it before, that T.K. guy knows his stuff!

    Have Fun,

    LyleHaze

    hello lylehaze,

    thanks for your answer.

    considering the pots event map of the core1:

    {0xbA, 0x01},   {0xbA, 0x02},   {0xbB, 0x01},   {0xbB, 0x02},
    
    {0xbA, 0x03},	{0xbA, 0x04},   {0xbB, 0x03},	{0xbB, 0x04}
    why it doesn't for 0xbB, 0x02 ? oh, wait.. I may not explain enough my stuff... parts of code involved are:
    const unsigned char pot_event_map[32][2] = {
    
    		//-------- AIN 11
    
    		// SR1 = instrument control 1 for channels 1-8
    
    		{0xb0, 0x03},   {0xb1, 0x03},   {0xb2, 0x03},   {0xb3, 0x03},
    
    		{0xb4, 0x03},   {0xb5, 0x03},   {0xb6, 0x03},   {0xb7, 0x03},
    
    		// SR2 = send B rate for channels 1-8
    
    		{0xb0, 0x02},   {0xb1, 0x02},   {0xb2, 0x02},   {0xb3, 0x02},
    
    		{0xb4, 0x02},   {0xb5, 0x02},   {0xb6, 0x02},   {0xb7, 0x02},
    
    		// SR3 = send A rate for channels 1-8
    
    		{0xb0, 0x01},   {0xb1, 0x01},   {0xb2, 0x01},   {0xb3, 0x01},
    
    		{0xb4, 0x01},   {0xb5, 0x01},   {0xb6, 0x01},   {0xb7, 0x01},
    
    		// SR4 = send A controls + send B controls
    
    		{0xbA, 0x01},   {0xbA, 0x02},   {0xbB, 0x01},   {0xbB, 0x02},
    
    		{0xbA, 0x03},	{0xbA, 0x04},   {0xbB, 0x03},	{0xbB, 0x04}
    
    };
    /////////////////////////////////////////////////////////////////////////////
    
    // This function is called by MIOS when a pot has been moved
    
    /////////////////////////////////////////////////////////////////////////////
    
    void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam
    
    {
    
    	// send mapped CC value
    
    	MIOS_MIDI_BeginStream(); // midilink encapsulation header
    
    	MIOS_MIDI_TxBufferPut((unsigned char)pot_event_map[pin][0]); // first value from table
    
    	MIOS_MIDI_TxBufferPut((unsigned char)pot_event_map[pin][1]); // second value from table
    
    	MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); // 7bit pot value
    
    	MIOS_MIDI_EndStream();	// midilink encapsulation tail
    
    }

    so the 3rd value is always sent... I GUESS!

    could it be an overcurrent issue ?

    I write again a very strange thing: it happens when I turn a bit the pot.

    not when the value is high at the beginning:

    - I start the midibox with this pot at 0. it boots correctly, everything works fine. I turn a bit ...issue!

    - I start the midibox with this pot at N>0. it boots correctly, everything works fine. I turn a bit ...issue!

×
×
  • Create New...