MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

es3/es5 and pure data setup
MUFF WIGGLER Forum Index -> Expert Sleepers  
Author es3/es5 and pure data setup
lilakmonoke
andrew ...

so i soldered the es5 to the es3 and this seems to work in pd at least partly.

even without using es5encoder~, if i send numbers 0-1 to the es3s corresponding channel the gates are flashing according to a secret code. i get the same gates for each number so as soon as i know the relationship number/gate i could program an abstraction to control individual gates.

i also compiled the es5encoder~ and installed the library. i can implement it inm pd but as soon as i connect the left outlet to dac~ pd crashes immediately with no error message.

im available for further testing, i also wrote you a pm about it.
lilakmonoke
i think i figured it out myself, its obviously binary again.

values 0 to 1 in pd = 128 possible states of the gates of the es5:
from 0000 0000 to 1111 1111, values -1 to 0 seem to do exactly the same

so one step of that binary series is 1/128 = 0.0078125. i just wrote a counter that counts from 0-1 like that and the es5 looks like a pachinco machine ;-)

but what i need to write is an abstraction that converts binary to float. that lets me control one es-5 but what happens if i have more than one?
os
The external works and does all this for you. You just need to get someone experienced in building pd & externals from source to get it to work - most likely my makefile is incorrect somehow.

The source is online now:
https://github.com/expertsleepersltd/externals
lilakmonoke
thanks! ill do all that but please stay with me and give us a few basic infos.

- your es5encoder code works in pd on mac and win already? so its just a compilation problem?

- ive figure out the basics already for one es5 but how about 5 of them? a 3 sentence description on how the encoding algo works would really help.

- maybe we dont need to compile anything and can to it all in pd native?

if this is done ill buy 2 more es5 and make you a really nice polyrhythmical demo video, i promise :-)

here is what i have so far:

this works for my one es5. im losing one channel of the es3 but gain 8 gates. here is the patch and the soundfile it generates.

http://tindeck.com/listen/imns

os
It works for me on Mac.

You don't want multiple ES-5s - you want ESX-8GTs attached to your ES-5. The 8GTs just use the remaining 16 bits of the 24 bit audio word.

Maybe it can be done in pd native, but it's going to be a lot more efficient in C.
lilakmonoke
andrew ...

correction: the above patch works for gate 1-7, not 8 strangely enough.

anyways, i just looked at the code and i understand NOTHING. if its a compiler problem i will do my best to motivate a synth nerd linux expert to fix it.

yes, of course the esx with the turbo GT engine AND the new 8MD i just saw on your site. then i can ditch all my midi interfaces and even power all the roland gear from there accurately.

expert sleepers for global studio domination!
lilakmonoke
i just recompiled it and its still crashing pd as soon as i switch on dac~. ive posted it to the pure data forum but i dont think anybody will get into it. debugging other_peoples_code is no fun. lets see ..

http://puredata.hurleur.com/viewtopic.php?pid=41296#p41296
lilakmonoke
andrew ... i cant find anybody who is willing to get into compiling your code and i simply dont have a clue.

ive spent another evening figuring out an abstraction that should do exactly what you describe with "The 8GTs just use the remaining 16 bits of the 24 bit audio word".

- it takes the first 8 bits and adds the remaining 16 as 0s.
- translates the 0/1 string into float and outputs.



this is really easy to do in pd native! but IT DOESNT WORK. the leftmost bit does nothing and im losing gate 8 and other unpredictable stuff. which bits in the 24 are used for what? PLEASE

i have no idea what i have to do to find out how the decoding EXACTLY works. ive asked nicely a few times and ive given this about 4 evenings now basically messing around with numbers and guessing wildly. if i dont get more info im giving up and that sucks big time!

im used to the general "you are dumb enough using linux so do all the work yourself" attitide but i think its totally inappropriate in the modular world.
os
Quote:
i think its totally inappropriate in the modular world

I think you're mistaking "the modular world" for "the open source/DIY world".

The external builds and runs fine on my Linux machine (RHEL6). To get it to run on yours I guess we need more information about what flavour of Linux you have, what compilers you have installed, how your pd was built etc etc.
os
Try the attached, which is the same thing but in C, not C++.
lilakmonoke
thanks, andrew!

compiled it and still crashing. somebody on the pure data forum compiled and gets the same crash ...

im beginning to think its connected to the 64 bit pd-extended im running (version 0.43.4-1~ precise) which is the official release but "somewhat experimental"?

upload the linux binary that works for you and ill test it on my machine. and again: if it can be done in pd native at least i would be happy for now.
os
Binaries attached.
lilakmonoke
thanks ... same crash as usual on my machine.

miwi from the forum also compiled and it works on his machine:

Quote:
yeah, it works on my end, or at least I think it does. I would have a better idea if I had one of these expert sleeper modules hooked up to my computer. All I can tell you is that when connected to dac~ and while being fed floats through the first inlet, it makes clicking noises and an especially large click when passing between 127 and 128


so if im the only one with a crashing binary it must be my pd/linux setup we should compare that also with miwis setup.

here is mine

kx studio clean install based on Ubuntu 12.04.3 LTS
kernel linux 3.8.0-32-lowlatency 64 bit
pd-extended version 0.43.4-1~precise, no pd vanilla installed
puredata-dev version 0.43.04 developer env

audio device:
rme fireface 800 via
ffado-dbus-server 2.1.0+svn2470-0
jackd

maybe its

- pd-extended vs. pd-vanilla
- or 64 bit vs. 32
- very possible! the ffado/jack device

so im going to test it with my internal soundcard and no ffado. also im going to buy a Expert Sleepers ESX-8MD tomorrow just because im not giving up! ;-)

thanks again for the support, andrew!
lilakmonoke
SUCCESS!

its the "callback" option in the audio settings for jack in pure data that causes the crash, whatever that is. if its on = crash, off = es5encoder~ works like it should weeks ago ;-)

actually even my soundcard seems to run better without callbacks now. ffado wouldnt run without it a year ago but with the new version its fine.

ah, the good lord and linux work in wonderous ways! im off to buy more expert sleeper modules.
os
w00t
lilakmonoke
w00t indeed! thanks again ...

now im going to get the esx-8md today and i really hope i can actually use it with my setup within the next year ;-) so you might disclose what numbers to input into the es5encoder~ to generate what midi code. or what bits to wiggle ... and again im willing to code this myself in pd if i know what to do.

always keep in mind that king linux will rule the world within the next 500 years!

.
lilakmonoke
so im guessing the answer to how to send midi messages via es5encoder~ is contained here:

Quote:
The MIDI protocol is made up of messages. A message consists of a string (ie, series) of 8-bit bytes. MIDI has many such defined messages. Some messages consist of only 1 byte. Other messages have 2 bytes. Still others have 3 bytes. One type of MIDI message can even have an unlimited number of bytes. The one thing that all messages have in common is that the first byte of the message is the Status byte. This is a special byte because it's the only byte that has bit #7 set. Any other following bytes in that message will not have bit #7 set. So, you can always detect the start a MIDI message because that's when you receive a byte with bit #7 set. This will be a Status byte in the range 0x80 to 0xFF. The remaining bytes of the message (ie, the data bytes, if any) will be in the range 0x00 to 0x7F.


in other words, if i string together correct 8 bit midi words and send them via binary -> decimal -> es5encoder~ -> es3 -> es5 -> esx-8md -> synth, im getting SUCCESS?
lacuna
.
MUFF WIGGLER Forum Index -> Expert Sleepers  
Page 1 of 1
Powered by phpBB © phpBB Group