lightning noise

[pilami]

hop je repose ça ici , j'ai fait un ptit systeme de balancier lumineux, qui triggent des synthés :

>> vidéo derriere l'image



prochaine évolution : un arduino derrière chaque capteur pour transformer en infos midi, pour contrôler des paramètres dans ableton =)

 

[makam]

       

[Luc Sassion]

interessant

[dwan]

prochaine évolution : un arduino derrière chaque capteur pour transformer en infos midi, pour contrôler des paramètres dans ableton =)

 

Re-

Sinon, un seul arduino suffira pour transformer tout ça en midi, ya largement de quoi faire  

[Jean Bender]

wé, j'ai bien vue ta video, c'est plutôt cool tout ça !! bien blasé de pas pouvoir voir ça en live au placard, mais bon, je desespère pas pour la fin de l'année ?? Hein !!

à bientôt pilami et BRAVO §§!!!

[krodelabestiole]

prochaine évolution : un arduino derrière chaque capteur pour transformer en infos midi, pour contrôler des paramètres dans ableton =)

oui effectivement, ya 5 entrées analogiques sur un arduino

ensuite si tu préfères midi à osc je te conseille au moins le midi 14 bit
(encodé sur 16384 pas au lieu de 128)
pour des changements de fréquences fluides

le truc c'est d'envoyer 2 control changes au lieu d'un, à 32 numéros de contrôle d'écart
par ex le cc10 va de 0 à 127 normalement
et le cc42 va de 0 à 127 chaque fois que le cc10 change de pas (par ex quand le cc10 va de 64 à 65)
cette norme commence à être assez bien implémentée (je suis pas sûr pour ableton ceci dit)
dans tous les cas elle est rétro-compatible 7bit

[pilami]

hu ca existe le midi 14bits??

sinon oué osc , ya bien moyen de recuperer des données osc dans ableton non? en passant par max ?

[krodelabestiole]

oui c'est utilisé pour les contrôleurs pour dj, pour la précision du pitch par ex
ça sert bien aussi quand tu balayes les fréquences audibles, que ce soit avec un générateur ou filtre, pour éviter le crénelage audible
c'est implémenté dans audiomulch 2 en tout cas, c'est le seul soft avec lequel je l'ai utilisé

[krodelabestiole]

pour osc disons que tu te galèreras moins pour le script arduino mais plus avec un patch pure data ou max to midi

mais sinon là j'ai mis un patch pd osc to midi 14bit :
http://www.mindthepressure.org/OSCtoMIDI.pd

il t'envoie 3 valeurs sur les ctrl change 20 21 et 22 (canal 1)
je me souviens plus des messages osc qu'il reçoit c'était pour un spectacle de corde lisse, tu peux éditer ça facilement

l'intérêt du midi 14bit c'est aussi que tu conserves une compatibilité hardware vs l'intérêt de l'osc : compatibilité wifi, web, ethernet

[dwan]

L'arduino a 6 entrées analo, et elles échantillonnent sur 10 bits (0-1023), et même sur 12 bits à l'origine je crois.

Je pense qu'il vaut mieux faire tout ça en compatible midi, ce qui te permet potentiellement de brancher le bordel à n'importe quel périph midi, quitte à ajouter un switch pour choisir entre 7 bits et 14 bits, au cas où tu le branches à une machine qui peut comprendre le 14 bits (genre ton ordi avec un patch max).

krodelabestiole, je comprends pas trop l'intérêt d'avoir un écart spécifique de 32 entre les 2 CC que tu envoies : ça change quoi ? C'est spécifique à audiomulch?

[pilami]

et surtout niveau débit ca risque d'etre limite avec du 14 bits non, au niveau de l'arduino?

[dwan]

Bah, une liaison midi fait du 31250 Baud. Si on reste en USB, on peut monter jusqu'à 115200 baud, soit 14,4 ko/s. Un message CC prend 3 octets, on peut donc envoyer 4800 messages CC par seconde au mieux, et environ 1300 à vitesse midi. ça devrait aller  

[krodelabestiole]

krodelabestiole, je comprends pas trop l'intérêt d'avoir un écart spécifique de 32 entre les 2 CC que tu envoies : ça change quoi ? C'est spécifique à audiomulch?

non c'est la norme midi 14bit
et c'est rétro compatible 7bit donc pas besoin de switch

la question du débit arduino est bonne
c'est assez flou pour moi ces histoires de débit et j'ai jamais implémenté de midi dans l'arduino
http://arduino.cc/en/Tutorial/Midi

MIDI is a serial protocol that operates at 31250 bits per second.

http://itp.nyu.edu/physcomp/Labs/MIDIOutput
je pense pas que ça pose de problème puisque le midi 14bit consiste simplement à utiliser 2 contrôleurs au lieu d'un

[krodelabestiole]

Bah, une liaison midi fait du 31250 Baud. Si on reste en USB, on peut monter jusqu'à 115200 baud, soit 14,4 ko/s. Un message CC prend 3 octets, on peut donc envoyer 4800 messages CC par seconde au mieux, et environ 1300 à vitesse midi. ça devrait aller  

merci pour les éclaircissements
donc effectivement 3 octets:
http://www.micha.fr/edu/spip.php?article43
donc le midi 14bit nécessite 6 octets -> 48bit
/ 31250 ça fait 650 messages par seconde
/ 4 capteurs lumineux
reste 160 messages par seconde pour chaque capteur
6 millièmes de seconde entre chaque capture

c'est p-e un peu limite effectivement

mais doit y avoir moyen d'optimiser le process et d'envoyer que les infos qui changent ...

[dwan]

C'est moi qui te remercie, je viens de voir que ma BCR2000 peut bosser en 14bits  
J'ai déjà implémenté du midi dans un arduino, et j'ai dû faire plusieurs fois la bidouille du 14 bits sans savoir que ça existait
Par contre en ce qui concerne la rétrocompatibilité, j'ai un gros doute.
Si tu envoies deux CC dont les numéros sont séparés par 32 à un périph midi quelconque, il va les interpréter comme tels, genre
"je mets le CC10 à 64 et le CC42 à 16"
et pas comme
"je mets le CC 10 à 8208"
Ça m'emmerderait grave.

En fouillant un peu sur Midi.org, j'ai vu qu'ils ont ajouté un truc à la norme, mais c'est pas le 14bits généralisé, juste une possibilité d'augmenter la résolution de la vélocité. On peut envoyer un message CC n°88 avant le Note On/Off. Intéressant, mais qui respecte la norme ? J'utilise presque tous les CC sur ma BCR  

High Resolution Velocity Prefix is intended to improve Note On/Off Velocity resolution while keeping
compatibility with older instruments. High Resolution Velocity Prefix is intended to be used when 7-bit Note On /
Note Off velocity resolution is not enough. In conjunction with this message, 14-bit resolution can be achieved.
This message is not intended as a substitute for any future data-resolution extension of MIDI.
[CONTROLLER MESSAGE]
HIGH-RESOLUTION VELOCITY PREFIX
Bn 58 vv
     vv = lower 7 bits affixed to the subsequent Note On / Note Off velocity
The velocity byte in the subsequent Note On / Note Off message represents the higher 7 bits of the velocity.
A single High Resolution Velocity Prefix message only affects the next Note On or Note Off received on the
matching channel. There may be other MIDI messages in between the High Resolution Velocity Prefix message
and the subsequent Note On or Note Off message. After the standard Note On or Note Off message has been
parsed, the lower 7 bits of the receiver's 14-bit velocity register should be cleared.
In order to maintain compatibility with the Note On Running Status shortcut (9n kk 00 acts as Note Off), the
smallest possible 14-bit Note On velocity shall be 0080H. The least significant bit of the upper 7-bit message is
set to 1, the same as the standard softest Note On message. The largest 14-bit velocity shall be 3FFFH. Hence, the
entire Note On velocity range consists of 16,256 steps. If 9n kk 00 is received, that still qualifies as a valid Note
Off, and the preceding Bn 58 xx has no effect.
If the receiver does not recognize this message, it will just ignore the message and accept only higher 7 bits of the
standard Note On and Note off messages.