thetechnobear's Recent Posts
it might be nice if Z could be switched between pressure and (note on)velocity
will the firmware be user upgradeable, handy if any bugs become apparent etc.
(and open sourced?!)
really looking forward to this, if you need early adopters/testers, Id love to help out.
(im definitely going to need more oscillators/filters and vcas :) )
cool... look forward to meeting you, Im Berlin bound tomorrow :)
Ive now booked my tickets for superbooth too... so will see you there :)
the issue with VCV rack is that they should have diverged from the 'physical world' for polyphony... i.e. where modules and cables could be polyphonic.. like they can in Reaktor (not blocks) and a few other software modulars (e.g. P900)
having used Reaktor Blocks with MPE, the novelty of wiring up multiple voices soon becomes pretty tedious.
one of those times, where the software version should be not restricted in the same way as eurorack.
(anyway this is why I didn't bother creating a T3D or MPE module, like I did for Blocks/Reaktor)
I checked Kaivo 1.3.2 with L10 , and it was fine too
when you lose the sound - does the little oscilloscope show anything?
Kaivo working fine for me in Live 10.
Im using Live 10.0.1b10, macOS 10.13.2, both VST and AU (64bit), latest kaivo (1.3.0 ?)
cool, much better :)
had a play over the last few days, and the tracker does feel better and in particular the top and bottom rows are much more reliable... i can now use them, before I found them too likely to trigger the row above - so this is excellent.
a couple of small bugs:
first, now only 3123 works , if you select another port (e.g. 3) in aalto etc, then SP app shows the new port (aalto(3) , but when you select it, you dont get any sound, and in fact its still sending OSC messages on 3123
second, i think your sending empty osc packets continuously?
(or the frame bundle has a bunch of empty messages)
if you do an oscdump you will see
/t3d/frm ii 10209708 65590
/
/
/
/
/
/t3d/frm ii 10209724 65590
/
/
/
/
/
/t3d/frm ii 10209740 65590
etc
ok, the OSC kind of works ;)
but you have something odd going on with the port offset....
the default for t3d is 3123, but you seem to be using 3125?
anyway the upshot is, is you need to set the osc offset in Aalto to 2 to work.
(using aalto 1.8.0, Kaivo 1.3.0)
from logs, look like you are connecting from 3125 onwards, and created an inbound socket for 3124... not looked for why this is yet :)
(also default in the dropdown appears to use 3125)
perhaps a simple change to move 0 back to 3123, and perhaps move your input port if required to 3122.
Starting Soundplane...
SoundplaneModel: listening for OSC on port 3124...
MLOSCListener: trying listen on port 3124...
MLOSCListener::listenToOSC: created receive socket on port 3124.
initializing pthread attributes...
creating listener thread...
MLOSCListener running socket.
---------------
SoundplaneOSCOutput: trying connect to ports starting at 3125
connected to port 3125
connected to port 3126
connected to port 3127
connected to port 3128
connected to port 3129
connected to port 3130
connected to port 3131
connected to port 3132
connected to port 3133
connected to port 3134
connected to port 3135
connected to port 3136
connected to port 3137
connected to port 3138
connected to port 3139
connected to port 3140
btw: any chance you could move the forum software over to Discourse, it really is much better forum software... and formatting options (for code) are much better ;)
anyway, this was just a quick sanity check... will hopefully have time to sit down for some quality time with the soundplane (on 1.7.0) later today :)
he he, i know how that goes ;)
what was the issue with the kernel panics? when i looked at this (on eigend) it was due to completion events being returned to a process that had been stopped/killed ... so all i could do was to ensure the process closed cleanly.
did you find another fix?
Have you had a chance to fix1.6 yet? I’d love to move to it, and also look at porting my code to it.
Thanks Mark
ah, those are the pesky kind of bugs...
hope the fix is not too difficult.
oops, bad news... the OSC t3d output seems to be broken...
its not working with Aalto properly, and when i look at the underlying osc message I can see its hanging on to notes that have been released, and its transmitting all 16 touches on every update.
ive tried resetting to factory defaults , recalibating, changing touches, rotate - all make no difference.
note: the touches display looks absolutely fine, so seems to be OSC.
note2: though ive not tested MPE... so could be interface between the touch model and the outputs.
Im going to have to rollback, or rather reinstall 1.5 for now :(
ooh, great news, can't wait to try this...
thanks for the continued development.
look forward to digging into the source again in the new year.
unfortunately, all my macs are on 10.12 now, soon going to be testing 10.13
one thing, apple change the usb stack significantly on 10.11...
but for my development, the issues i encountered were the other way - things working on 10.10, started crashing on 10.11+ ( they have been slowly improving). that said, i didn't have to alter anything (other than ensuring the apps closed down the usb connection correctly).
sorry, not helpful, but perhaps useful to know why 10.10 is likely to be different to 10.12 (and probably 10.11/10.13)
is the code base now stable, and in GitHub? or are you still working on it?
are the changes done for the embedded/eurorack system?
if its not under going significant changes, Id like to update my fork, to bring in some of my changes (midi/note offset visualisation)...
and also use if for rPI etc (will be interesting to see performance impact on non-desktop systems)
works fine here ... macOS 10.12.6 :)
@Sanne.... this works as expected for me in Live 9.7.4 / Mac OS X.
i.e. in arrangement , start record, it tracks all changes, when you switch presets it records the new values, and subsequent changes...
and no need to hit rearm automation.
(it works identical in Aalto as for other plugins e.g. u-he diva/ace )
one thing you do need to be careful of, is when you do playback, you must start aalto in the same state as you did when recording ... which Randy in his OP alluded too.
you can achieve this in one of two ways
- use a program change on the recorded clip (MIDI Programs folder)
- when you start recording, switch to your starting preset (and hence save all automation values)
as fars as I see this achieves what you want... i.e. start recording, select preset, alter values to get a nice sound, repeat many times... then use playback, and find the place you liked... stop, and hit 'save preset as'
note: when you do playback it will NOT change preset name, this is because ableton is as such recording the preset change, just recording the values of the preset.
... btw: i didnt try changing presets via Program change messages, Id assume that would be recorded. (though you'd have to be careful between sessions to NOT change your program ordering )
@randy, I dont think aalto needs to track changes, surely this is exactly what DAWs do with automation, why replicate the functionality... the only thing id prefer, is an easier/quicker way to assign program changes. perhaps just assign to existing presets into different banks/programs #. (rather than copying presets around)
ideally what Id like is...
a) updated Aalto with more voices but apart from that the same.
b) a completely new instrument, kind of similar to Aalto ,but not Aalto 2, that would not need to be patch compatible i.e. not limited/shackled to what Aalto does already (so well)
(u-he are doing this with Zebra 3, they already have said it will not be compatible with Zebra ... I think they said they will allow imports of patches, but they may/will sound different)
I do agree about Kaivo, I don't use it as much as I thought I would (and no where near as much as Aalto) because its resonance peaks are really hard to contain... I find its quite a small zone of usability, perhaps within only an octave. (pitch can wander too, but I think thats part of the beast)
anyway, Id love to see another out n out synth from ML...
also perhaps we can skip the sequencer, so we can have a bit more UI real estate for voice control... I know alot use the sequencer, but is it not easier to just use the sequencing/automation facilities already present in every daw (or use a MIDI sequencer VST)
if I want to build, is the 'embedded' branch, the latest and greatest? and are all the necessary changes to madronalib already checked in?
also do you know if the cpu load has dropped with the new tracker?
generally, thinking about updating my fork, to get my midi goodies... and also the mec repo, so I can test it again on my bela.
so I got distracted and left the SP turned on for about an hour or so, untouched - when I came back there were lots of green patches in the middle...I had to turn it to 0.20 to get rid of them all.
but then by chance, I decided to hit 'recalibrate' ... and they all disappeared, even when turned down to 0.10 .. is this what you would expect?
this is all great news :)
if you can improve the boundaries, that will make a huge difference for me, in the previous version I rarely used the top/bottom rows, as I couldn't be 100% sure it'd trigger the correct note.
when doing the boundaries, perhaps you can also work out (or even estimate) the useable area of the top and bottom row, so that why can be scaled to that...
e.g. if 50% of the top row perhaps its better, to have Y run 0..1 over that 50%?
another observation, so you talked about x/y and turning up to x10, and then using lo thresh to get rid of green patches... so I did this (though even without , I wasn't getting false triggers) , I turned it up to about 0.12-0.13 (default of 0.10).. and they disappeared, but noticed after about 5 minutes of playing, they seem to be appearing again, so turned it to .14, gone, then a few minutes, .15 etc...
but got distracted, turned off the SP/SP app... can back after a while, and noticed I could turned it down to .12/3 again
always the green patches in the same area (centre, most played/worn ? ... I couldn't really figure if this was a 'software' issue, or if the surface is 'warming up', perhaps not returning to the 'same point'
thoughts?
( as I said, it wasn't causing any false triggers, I was merely following your instructions above-- so perhaps this is expected, nothing to 'worry' about)
This version definitely feels like a great improvement - congratulations, thank you for putting in the effort to bring about these improvements.
generally, I think the close touches register much better, and its a more consistent feel, and its great to not have the calibration step :)
a couple of things
midi, is still a bit hit n miss for me, in particular the velocity is a bit on/off still... also if you try quickly alternate between 2 different notes quickly, sometimes this will be considered a PB rather than new notes. ( the lopass , seems to have no affect on this)... if you x/y view you can see its thought of as a slide rather than a new touch.
i usually use OSC, and pressure rather than noteon/envelopers so its not a big deal for me, but to use with non ML mpe synths, improving these would help alot.
calibration, as i said seems to work well without it, the only exception to this, is i notice that sometimes the 'line' between row 1/2 , 4/5 is not detected as straight. so if you play a note high on row 2, somtimes it play as row 1, or a note low Y on row 4, it detects as row 5.
obviously this only is an issue if you play with 5 rows of notes, which I like to do, to give me a bit more range (of notes).
... what would nice is if we could draw the row boundaries with our fingers (in a calibration mode), then the software could use these to find the notes, and interpolate the Y position.
it is only an issue in a few places on the board, so i currently play around it.
as you say, I'm also getting used to the fact, that if you play one touch, hold it, and add another touch close (so a chord) it does require more pressure - guess it will take a short while to get used to this, but definitely worthwhile for the other advantages.
as i said really grateful for the effort you have put into it, its hard to tell with 'feel', but from my initially playing it does feel like a big improvement.
Big thanks
Mark
p.s. let me us know when the source code is up to date for SP and ML repo, as id like to update my fork to use the new code :)
I'll pause the Soundplane work
oh, don't do that, Ive been holding my breath, and I'm going to implode if it doesn't arrive soon ;)
yes, Ive been running some of the soundplane code on bela.
basically Ive take a subset of madronalib and soundplanelib, and put it in the project I'm working on (called MEC).
you can find it here,
http://github.com/TheTechnobear/MEC
its under mec-api/devices/soundplanelite
Ive found Bela is not really quite powerful enough to run the full touch tracker... its close, but not quite there. it is however ok for the raw data.
However, Randy is working on a new version of the touch tracker code, which I believe he previously said should take less cpu, so once that is ready I will move over to this newer code.
note: this is with a soundplane model A, ive no idea how compatible/or not, this is with the DIY version.
Sounds like an excellent challenge, look forward to seeing the results
I like the idea of this with MPE, but how would it work?
it seems to me, that if you have mono voices, and then a separate component taking these as input and processing the same MPE messages as the synth.
then you are relying on some kind of fixed allocation e.g. channel 2 = voice output 1, 3 = vo2.
this works in a simplistic way, but most mpe enabled synths do not have this fixed relationship ... the voice number is not related to the channel number directly (of course its tracked, so that messages from that channel are routed appropriately)
this I think is done for 2 reasons:
the midi channel range may be greater than number of voices, and also it may be using rotating channels. (e.g. its setup for channels 2-15) but only hits a synth with 4 voices... it should still work, just your limited to 4 voices.
mpe allows for polyphony on one midi channel e.g. say you have an mpe zone, with only 4 midi channels allocated, it allows for you to still play (e.g) 6 notes, albeit that you only get per note expression on 4 of the notes.
ok, I know aalto doesn't do either of these things, but certainly I think it should do the first one at least.
oooh, beta... now I'm excited :)
Is in the first sticky thread, on this sub forum ( Soundplane client for Mac)
http://madronalabs.com/topics/1691-sticky-soundplane-client-for-mac
Probably should be a link to it in the Soundplane production page too.
(Or perhaps I missed it ?)
Of the USB to MIDI DIN solutions, aren't they mostly USB Devices?
yes, most are, which is why you want to support usb hosting by being a usb host ;)
USB devices are hosted, this is not limited to controllers e.g. A synth that has a USB interface would require USB host, supporting USB midi class compliance.
This is becoming increasing common, and makes sense for MPE hardware given the bandwidth requirements of the data.
It also largely makes din irrelevant, since there are lots of USB to din solutions , which contain flexible routing options, I guess it's convienient but takes up rack space.
As for iOS , as long as you are class compliant it's not an issue, it just works - this is how we connect Axoloti to iOS.
Is the midi for Soundplane output? If so USB midi ihost is better than midi din.