thetechnobear's Recent Posts
I like using the matrix on Xils version of VCS3, and it does have the advantage of almost unlimited expansion, and I think provides a better overview of current modulations and routings (as wires don't cross) than the patch-bay.
but on the flip side, Aalto is MUCH less fiddly to use, and I think more intuitive initially.
my fear is the patcher is getting hemmed in, there are a few extra modulation sources (e.g OSC strips) and targets (e.g. envelope control, wet/dry levels) that would appear a lot of work to add in the UI... whereas the matrix would be easy.
I cannot imagine, how this concept is going to work with the 'future' full ML modular, I don't think they'll be enough exposed space on one edge of each modular.
but having both, I think may be a lot of extra dev work, for little benefit.
perhaps, Aalto could move to a system similar to the make noise modular?
so allow wires to go between any location in a module (like bazille/ace etc), but have a CV shared bus, which allow some of the more common CVs to be made tidy in the middle.
I say this, as I think in UI terms, this shared bus could be quite similar to the current patch bay concept, but perhaps just a little more organised (=rigid) e.g. run the bus in parallel lines, with same colour cables, and possibly take a little less space, so that the modules can have more space... which could then be used for the extra CV inlet and outlets.
another idea, would be to extend the patch bay, along the edges of the modules, so have some space between each module, and route the cabled up there and into the side...
not very conventional, but would keep the module face clean, and the inlets could be closed to the associated control (vertically).
but hey, UI design is hard... cramming too much functionality in, makes things complicated and ultimately less useable, and I think the clean design is one of the reasons why I use Aalto so much. ( I also use Valhalla plugins for a similar reason), and Im confident Randy has considered all the above before, and decide against, or has 'a plan' :)
an interesting article, relevant to playing a soundplane
I think most of us stick with the fourths layout, so the above article is relevant.
(i tried alternative layouts, but didn't find they had any advantages, though i do like chromatic too)
what the article does show clearly (actually RL posted before) is the reliance on using adjacent cells (possible on the LS, but not currently on the SP). but you can also see from the diagram the other possibilities, and its interesting to find these, and see if they are comfortable.
of course scales/chords are not everything, but they are a pretty important foundation to playing pieces.
my general observation, would be the LS shapes lean towards a more 'vertical' fingering for chords, this is not surprising... as the horizontal can be a stretch, and in this manner the LS has more rows (perhaps to accommodate this?)
but is this natural? ergonomic?
Im not so sure...think (or better try) how you need to hold your hands, and particular your wrist, it tends to need to be rotated... (unlike a piano where it stays parallel to the keys),
but perhaps this 'the technique' for grid playing?
in 'fairness', I'll say on the eigenharp, I do similarly rotate my wrist (particularly in the right hand) and its not an issue...
so its an observation, not a criticism.
btw, a few of us euro eigenharp players gathered a few weeks back, and it was very interesting to hear/see about different playing styles and approaches to the instrument, I learnt a lot (as did others I think) about techniques that Ive been slowly trying to incorporate.
this is why Id be fascinated to hear how others approach the soundplane...
with such a 'blank canvas', Im sure we all take a slightly different approach,
I thought it would be interesting to start a topic to see how people play their Soundplane, and tips and techniques they have developed.
Ive only had a soundplane a short while, so I'm still learning to play it, but my approach is to treat it as 'a unique instrument' which will needs its own techniques/approach.
( I learnt this was the best way for me, when I started with the Eigenharp)
Some basic questions:
a) Playing Surface (i.e. notes) or Control surface ( x/y, sliders)
b) Preferred layout
c) Single part (eg solos), Multipart (e.g both hands)
d) What do you find difficult?
e) What do you enjoy doing most, or is unique to the Soundplane?
I use Kaivo on 3123, and then in Aalto (v)1.6.1 set its offset to +1, so its on 3124
I used to have the same issue with 3124 and was working with 3125 but, either Aalto v161 or the new soundplane software fixed it (I think it was the later?)
looking forward to a new Kaivo with this though, partly for splits, but also so I can have one instance for the soundplane and another for my eigenharp. (over osc)
Ive been thinking about split support... and got some ideas brewing for that :)
as you say, ambient and slow moving stuff is a joy to play on the soundplane :)
chords - interesting, I will try these, i guess sometimes I focus too much on the centre row rather than bridging row 2 & 4 as you are.
Eigenharp, breath is a great addition, its very sensitive and its great to 'breath life' into synthesised sounds :) generally the Eigenharp is very different to the Soundplane, very lively, precise, sensitive, quick - all make it very expressive. of course it lacks the the continous nature of the soundplane, but for me thats what makes it a perfect complement to the soundplane. I love them both :)
(btw sorry leesifer didn't see your comment, so been awhile to reply)
@randy, cool, the touch tracker is the heart (or brain?) of the soundplane, looking forward to your new work on it :)
a few months ago I got a soundplane, but did seriously consider a linnstrument. I've also got an eigenharp, and also recently was able to spend some quality time with a continuum.
chords.. perhaps have a look at this [url=http://madronalabs.com/topics/4085-how-do-you-play-your-soundplane]thread[/url], it details how Im playing chords, and also the current limitations. (that Randy is working on :))
first, id say the soundplane/eigenharp/continuum all feel completely different, none is better just different and id suspect the Linnstrument will be different again. what works for you will probably be down to what you want to play and prefer.
the big deciding factor for me (except the beautiful look and feel), was the Linnstrument can only slide in the Y axis for one cell, unlike the soundplane/continuum which is fully continous.... so in that regard, yes its closer to the continuum. (but again, the continuum is a very different beast, due to pressure axis/eagen matrix )
also at the moment, the 'standalone' nature of the linnstrument, is important to some, but for others (like me) not as important, or the potential CV box for the soundplane could be perhaps important to some.
whats important to you?
your welcome, enjoy :)
ok, did a bit of checking on the windows side...
at the moment libusb does NOT have winusb iso support implemented,
however there is a patch available that makes iso support available liubusb via libusbk... which has the advantage, it works on older versions of windows but is more hassle to install.
I may be 'digging' in this area in the next few months (with the soundplane and eigenharp), if I do, I'll let you know.
Ive recently developed stuff for the EigenD/Eigenharp using libusb (including isochronous io), currently Ive tested with linux (including PI2) and works fine.
For the Eigenharps, Eigenlabs wrote (contracted? unfortunately its the only bit I don't have the code for) a small driver, which basically replicated an iso transport into userspace with a 'generic driver'
my understanding though, is that from Windows 8.1 this is no longer necessary, as WinUSB supports it... Im quite tempted to now test this, as libusb* supports this, so theorectically my code should work as is :)
*this assume libusb, has been updated to support the new iso functions in winusb, Ive seen "issues" asking for it to be added, but have not checked the code yet to see if it was.
I think libusb would be the way forward, when this happens as you will get both linux and windows (and also potentially OS X) with the same code base, but it does look like it would be 8.1 would be the minimum supported version, without going the Eigenlabs route.
btw, it may be possible the Eigenlabs driver could be used, as it has no specific eigenharp code* in it, it just forwards requests from a userspace layer into the generic driver...
*hmm we'd have to check its not castrated the vendor ID... you could perhaps even talk to John to see if he might work with you on a derivative driver?
in midi mode , it appears fast slides are generating 2 touches. (22.214.171.124)
( I say midi, its probably unrelated to midi, as you will see below - but its where its easiest to see/hear)
e.g. say you fast slide across the entire surface, you will see (correctly) one slide for the whole slide, but you will see (incorrectly) additional small slides (which look almost independent)
params: quantize on, glissando off, note lock off (everything else default)
replication: easy use 126.96.36.199 midi mode, aalto, patch default, sustain=max, rel=0 and voice = 1 (important) , then slide fast. you will hear the note stop before you reach the end.
ive not fully debugged, I can see in midi monitor 'additional' touches are on different midi channels - this seems to indicate msg->mData is different, as this is used for channel i.e. different touches.
this is also 'confirmed' by the fact if you set max touches = 1, then the problem goes away... presumably as the rogues additional touches are being ignored by the touch tracker.
but oddly only one touch shows on the graph,
not a big problem, but seeing as you are looking at touch tracking, perhaps something to test
it was a fantastic weekend, "we were like kids in a candy store", really inspiring to play so many different instruments.
fascinating to see how the Soundplane/Continuum/Eigenharps all take a different approach to expression, and feel like completely different instruments, each a unique character... we saw that even playing the same synth/patch on different instruments, results in a completely different sound.
Christophe was amazing on the continuum, Ive come away thinking about the techniques he uses, to see if I can perhaps adapt some of them to the soundplane.
oh, and amazing to see how many of us had Aalto/Kaivo paired up with an instrument... there is something about physical modelling and these instruments that just 'feels right'
select carriers - I can't reproduce this one.
hmm, odd, I tried this a few times, and it happened each time. Im now wondering perhaps if it was all 'in the same session' , perhaps a restart of the app would have fixed it, i.e. a quirk, if I get it again, I'll try to get some more info on what is going on.
It's important to me to have nice sensible defaults going forward.
fair enough, more an observation... always tricky, with these kind of things, but as you say better to have it 'correct' going forward.
cool, will give it a go tomorrow
now I can start in earnest on the new algorithm.
played now for a couple of sessions, does feel better...
there appears to be a new bug (188.8.131.52), now if you do "select carriers" ... the SP will initially not do anything, until you also hit 'recalibrate' - not a biggie, but might catch a few out.
cool, will test it :)
Im a bit surprised you have moved the offsets, I know the labelling of the notes was wrong, but I would have thought most, would have got used to note positions, so changing the offset might cause some confusion. (I know you can transpose)
I thought you would probably just change the note names, I know inconsistent with guitar tuning, but id assume its what most users have got used to?
the soundplane software (1.2.4) has introduced a bug which meant it only connects on the default port - Id already reported to Randy. But Ive also now debugged it, and supplied the details of the fix to Randy.
its a trivial bug/fix so hopefully ML will release it
note: you will need to use Aalto 1.6.1, as 1.6.0 also had a bug related to using multiple OSC addresses, and also incorrectly reported 't3d connected, when it wasn't'
ok the issue is in :
void SoundplaneController::doOSCServicesMenu(int result)
the parameters in resolve passed in incorrect order.
Resolve(getServiceName(result - 1).c_str(), kUDPType, kLocalDotDomain);
Resolve(kLocalDotDomain,kUDPType,getServiceName(result - 1).c_str());
have you had a chance to look at the multiple OSC issue I reported via email?
(ie. when using osc offsets, so I can have kaivo and aalto running, worked in previous release of SP software)
if not no issue, then I will fork repo, and fix it... but don't want to duplicate effort.
p.s. any chance of a tag/branch on the madronalib/soundplane repo for released versions. i.e what makes up 1.2.4
love almonds :)
dry by european standards, as no rain from June-August, but some rain the rest of the year.
We run off our own well, which is about 20 meters deep.
btw, today had an issue again... i noticed that the carrier i was uisng (2), had jumped to 0.08, and now carrier 1 was better at 0.04 ... so perhaps these changes are why im getting these issues.
just not why sure the noise changes so much ?
ah, although I'm from the UK, I now live (~2 years) in southern Spain on an old almond farm in the mountains close to the Sierra Nevada - its very beautiful, especially now as the almond trees are in flower.
but... no supplied infrastructure, so I have solar panels (with backup), my own water supply (treatments/storage), and for heating - solar thermal panels, a biomass incinerator which uses almond shells (a 'waste' from the almond farms), and wood burners (to burn cuttings from our trees)... and fortunately, recently, internet via WiFiMax (used to be satellite)
Its alot of fun, but still very much a 'work in progress' :)
hmm, interesting, I can see this behaviour too.
CCs are ignored until the first note comes in...
odd, it looked like an optimisation on Lives part.... but Kaivo doesnt have the same behaviour,
... so either the plugin is telling Live not to send until first note, or aalto is not responding to the CC or flashing the mod light.
@antolyi/randy, just tried here with Mac/1.6.1 vst/Live9 (also N4) ... and works as expected.
I tried first with default MW, ok - then changed CC# to 10, and checked Mod worked on 10, Mod+1 on 11 , both seemed fine.
perhaps a Windows or host (daw) related issue? which daw? does the mod input flash?
Im out of my depth here...so may be talking nonsense :)
UK/US, I assume your referring to mains hum, and the difference between europe using 50hz vs US 60hz... and I guess that implies different carrier frequencies are suitable for europe? Im assuming you have to be careful of harmonics of these frequencies too?
Q. what are the frequencies used by the SP? Q. are the choices of carriers 'hardwired' in the SP, or could we potentially have different choices in europe?
off gird, I was referring to the fact some mains supply cans be pretty 'dirty', with pretty big voltage changes (dips and peaks) as demand alters... and was wondering if this also might induce different RF interferences (and so implicitly change which carrier signals are better)
but as I live in the mountains and don't have mains, I don't have this issue. my solar system has very stable voltage (+/-0.2v variation according to my metrics, which is tiny compared to mains swings which can typically be +/-5v, and at times by much more than that).
Ive read these voltage changes, can make equipment operate differently (sub optimal), but again... Im only going on what Ive read rather than seen any real evidence of it.. not sure if it affects the 'hum' of not.
(the reference to inverters... these, as you possibly know, take my 48v DC to 230v AC, but not all inverters are 'equal', in terms of voltage/cycle variations and some don't even put out perfect sine cycles... so this is something I was very careful of, when designing my system, as well as ensuring I have good earthing, and no ground-loops :))
saying all this, I've not finished building yet, so I'm in a temporary studio, which has a lack of plug sockets, so quite possible the huge number of power strips I have could be far from ideal :)
noise results are:
so carrier 2 is selected.. which I'm 'fairly' sure is always the one selected.
But whats interesting is I'm pretty sure, there used to be 2 (carried 1 and 2) that were around the same 0.004 level, sometimes it would choose one, others time the other.
now 2 things have changed....
a) Ive moved my gear around a bit, due to getting a new mixer in the studio.
b) Ive put a new (powered MTT ) usb hub in place,
I just noticed, if I plug directly into the mac, that carrier 1, goes back down to 0.0048 levels, from 0.00758 ... so I'm wondering if the new hub is creating a bit more 'noise'.
(the usb cable is, I think, the one supplied, and has a ferrite block on it)
so... a couple of questions...
is there anything i can do, to ensure noise is not an issue, or reduce it?
is there anything I should avoid? ( my SP usually is played in from of the mac)
also, next time I see, the issue, I will do a carrier scan, and see what its says, e.g. has the noise gone up.
(when the issue has occurred, Im pretty sure I've not been doing anything to USB devices, or turning any other devices on ... and my power supply is pretty clean, as I'm off-grid running off of solar power with good quality inverters :))
EDIT: actually scrub the 'new hub' theory, just did a few more scans, and even in the new hub its sometimes at 0.004 levels, seems carrier 1 is a bit 'random' on its noise levels.
@mtvic, Live 9.1.7 + Aalto AU 1.6.1 + OSX 10.9.5 works for me :)
sorry not much help ... might be work rescanning/reinstalling?
thanks.... Im pretty sure I was using 1.1.2 before but I guess same place modified url :)
yeah the ghost touches are odd... they occur in a couple of forms...
a) a random touch, quite far away from where other real touches are... i think these tend to be on on the bottom row
b) if play a tri chord, I get 4 or 5 touches (i.e. 2 extra) quite close to the other 3,
(a) is a pain, as the touch tends to persist, until I hit the recalibrate button (pg 2)
also, If i turn up the view scale, it does indeed look like the SP has a touch in that region.
and it also seems commonly in the same place ... bottom row around column 6 (approx)
but it just suddenly starts... I've not placed a touch close to there, and it might start after 5 mins or 30mins!
(b) bit different, but again fine for quite some time of playing, and then suddenly will start glitching, not all the time, but once its starts seems to be more likely to reoccur.
the above are just 'impressions' rather any serious quantifying/testing... but definitely didn't occur in 1.1.2 (which is I'm pretty sure what I was using before)
I did have a try with the reducing template (its about .300) but didn't appear to help, but will try more 'rigoursly' :) threshold Ive got at the default 0.010, but will try to increase.
(I'll look at the ghost touch pressure value a bit close next time, I assume I can use that to tune thresh)
BTW: an idea for you.
I really like the 'pressure value' display on the grid,
I was wondering if we could have something similar for a musical context....
Im trying to get better with quantise OFF, and I'm ok with single touches, as i can tune to a 'backing track'.
BUT when Im doing multiple touches its very difficult, the issue is, I can hear one of the notes is OFF, but its hard to determine which one...
so I was wondering, if we could display a 'tuning' offset for each touch,
this would be a useful training aid, as I could see which note was off, and tune it by ear.
there could be other representations ... e.g. the touch colour could be different for sharp/flat/in-tune.... this would be cool, as very quick to see.
(Im guess not really interested in how much Im out, just which touch and in which direction, just a clue... to then let my ears do the real work :) )
will get back to about the ghost touches, if I can determine anything more concrete to help.
Is there somewhere I can get the previous version from? (I stupidly overwrote it)
Im getting some issues with 'ghost' touches that I didn't get on the previous version, and I need to 'perform' with the soundplane in a couple of weeks, so much as I prefer the new version ... I cannot risk the ghosts touches :(
also, when I go back, will I have to recalibrate?
(It would be nice I think to have a separate app state for each version, in case you need to rollback/ or use different versions for testing)
nice release, already improves touches on the edges for me, and I like the new pressure display. I've emailed you a couple of minor issues, but overall feels really good.
looking forward to seeing and hearing more about the new generation touch tracking :)
my #1 requests would be improved handling of tri-chords, which can be a little hit/miss... but a tough challenge I'm sure, given the 3 notes are quite close.
( though >1 cell apart)
When you log in to the this site, top right you will see a link "my downloads"
(Underneath your login name, my account etc)
apart from this project is going to involve me going down the modular rabbit hole, I'm really excited by it :)
a couple of thoughts
this discussion scares me, Id get a modular to get away from computers, Im not keen on integrating them... am I the odd one out on this?
Id really love it to be simple, and do one job really well, direct connection of the soundplane. Im sure the architecture will be open to expansion anyway, so no need to over complicate at the beginning? keep it simple ... conquer the world later.
In this vain, Id have thought something like:
micro controller with limited storage (need for SP touch tracking software - no?)
upgradeable firmware via USB, and also allow upload of small files (e.g scales/zones), or possibly this could be done via micro SD, but not sure a slot in a non-clean environment is good option, also adds cost.
open source firmware
8 CV out, default assigned to 2x X/Y/Z/Gate BUT by assignable to whatever via firmware (so future firmware could have zones which use as 8 faders)
2 endless encode with small readout to show values, addressable via firmware (example use might be to change scales/zone mapping)
2 CV in (by default, drive the endless encode values)
expansion connector to allow for additional banks of CV outs etc.
Note: Number of CV outs/in I guess this will be driven by cost, and keeping the module 'affordable', which was stated as the goal.
with this kind of model the initial firmware could be very simple (and rock solid!), but could could easily be extended to cover different zone mappings/scales, or other imaginable uses.
open sourcing the firmware, could help relieve some of the pressure on ML.
ML is really creative and is always coming up with fantastic ideas and products, so Im sure we (users) have to be realistic about how much effort can be put into this project (without letting other ML projects suffer)
awesome stuff... OSC and automation working great here... thanks!