Maybe I should tackle an Amiga port at some point in the future?ThomasHelzle wrote:"Guru Meditation" and a meaningful number is all we need
Cheers,
Tom
!Epoch, for the next 4 years
-
- KVRAF
- 2681 posts since 25 Aug, 2003 from Bournemouth, UK
Architect, the modular MIDI toolkit, beta now available for macOS, Windows, and Linux.
-
- KVRAF
- 6305 posts since 9 Dec, 2008 from Berlin
That would be awesome!colin@loomer wrote:Maybe I should tackle an Amiga port at some point in the future?ThomasHelzle wrote:"Guru Meditation" and a meaningful number is all we need
Cheers,
Tom
Think of all the cool 8 bit sounds we could use again... Maybe build in a direct link node for Kings/Space Quest and Leisure Suite Larry running as sequencers...
Tom
"Out beyond the ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there." - Rumi
ScreenDream Instagram Mastodon
ScreenDream Instagram Mastodon
-
- KVRAF
- 1893 posts since 12 Mar, 2004
Obviously you didn't keep up with the scene hahahacolin@loomer wrote:Maybe I should tackle an Amiga port at some point in the future?ThomasHelzle wrote:"Guru Meditation" and a meaningful number is all we need
Cheers,
Tom
Would that be an OS3 port or OS4 port, or maybe Morphos, or maybe AROS or Amithlon hahaha
Duh
-
- KVRAF
- 2681 posts since 25 Aug, 2003 from Bournemouth, UK
It's time for a quick update, certainly. I've had to rework the message passing system, which turned out to be pretty inefficient when dealing with large data, be they sysex messages or simply long structures.
Previously, each module would produce a new output message based upon its inputs, which in many cases could result in a lot of duplication - a significant number of modules, such as macro inlet and outlets, or switches, result in message(s) identical to (one of) their inputs. By switching over to a reference counted solution, said modules now simply hand off the exact message they received instead of having to creating a duplicate. Result: 50% reduction in CPU time even in simple cases, and many many times that when you have a patch that does a lot of sysex processing.
I debated whether to put off reference counted messages until post-beta, but in the end, and after profiling in detail, it turned out that this message creation was constantly a significant processor hog (relatively speaking: overall, the CPU usage is very light-weight; my more complex generative creations, which have perhaps a a thousand modules, still barely register a hit on the CPU.)
I'm now working on fixing the method by which one can write to sequencers, tables, arrays, grids, etc. I first had a system where to write to a sequencer you'd use an indices inlet and a per-parameter values inlet. So, to write a chromatic run starting at middle C to steps 4, 5, 6, and 7 of a a sequencer, you'd pass the indices inlet a '4', and then pass a list of values to the pitch inlet, eg, [60, 61, 62, 63]. You could also pass a list to the indices if you needed to specify exact step write destinations; passing [4, 6, 7, 10] would mean that you would write to step 4, 6, 7, and 10.
The problem with this was that often, with generative pieces, you'd fine that you'd want to write to different steps for different parameters - maybe you're changing certain step velocities, but other step repeat counts. So I added a per-parameter indices inlet, which solved this, but things got messy. Whilst you can hide unused inlets and outlets - and by default, most on the more complex modules are hidden so you're not immediately confronted by a module with some hundred-odd terrifying inlets! - it turned out to be a routing nightmare to have to essentially connect two inlets up for each modulated parameter.
I'm now in the process of switching over to a tuple-based solution. One inlet per modulated step parameter, but that inlet can take either: a single step index and value tuple - (4, 70) would mean write value 70 to step 4; or a list of tuples, [(4, 70), (5, 72), (8, 48)] would write 70 to step 4, 72 to step 5, and 48 to step 8. And it's working wonderfully; !Epoch has a lot of really good list processing modules, so producing tuples to write to a whole range of steps is easily done with a Range (to specify the destination steps) and Zip module (to combine the range and values lists into a list of tuples.)
All this likely sounds much more complicated than it actually is, but in truth, its a pretty simple system. Once you get your head around the fundamental - which is basically, similar to vvvv, that one should favour lists over iterations - it's a simple, consistent and logical environment.
Previously, each module would produce a new output message based upon its inputs, which in many cases could result in a lot of duplication - a significant number of modules, such as macro inlet and outlets, or switches, result in message(s) identical to (one of) their inputs. By switching over to a reference counted solution, said modules now simply hand off the exact message they received instead of having to creating a duplicate. Result: 50% reduction in CPU time even in simple cases, and many many times that when you have a patch that does a lot of sysex processing.
I debated whether to put off reference counted messages until post-beta, but in the end, and after profiling in detail, it turned out that this message creation was constantly a significant processor hog (relatively speaking: overall, the CPU usage is very light-weight; my more complex generative creations, which have perhaps a a thousand modules, still barely register a hit on the CPU.)
I'm now working on fixing the method by which one can write to sequencers, tables, arrays, grids, etc. I first had a system where to write to a sequencer you'd use an indices inlet and a per-parameter values inlet. So, to write a chromatic run starting at middle C to steps 4, 5, 6, and 7 of a a sequencer, you'd pass the indices inlet a '4', and then pass a list of values to the pitch inlet, eg, [60, 61, 62, 63]. You could also pass a list to the indices if you needed to specify exact step write destinations; passing [4, 6, 7, 10] would mean that you would write to step 4, 6, 7, and 10.
The problem with this was that often, with generative pieces, you'd fine that you'd want to write to different steps for different parameters - maybe you're changing certain step velocities, but other step repeat counts. So I added a per-parameter indices inlet, which solved this, but things got messy. Whilst you can hide unused inlets and outlets - and by default, most on the more complex modules are hidden so you're not immediately confronted by a module with some hundred-odd terrifying inlets! - it turned out to be a routing nightmare to have to essentially connect two inlets up for each modulated parameter.
I'm now in the process of switching over to a tuple-based solution. One inlet per modulated step parameter, but that inlet can take either: a single step index and value tuple - (4, 70) would mean write value 70 to step 4; or a list of tuples, [(4, 70), (5, 72), (8, 48)] would write 70 to step 4, 72 to step 5, and 48 to step 8. And it's working wonderfully; !Epoch has a lot of really good list processing modules, so producing tuples to write to a whole range of steps is easily done with a Range (to specify the destination steps) and Zip module (to combine the range and values lists into a list of tuples.)
All this likely sounds much more complicated than it actually is, but in truth, its a pretty simple system. Once you get your head around the fundamental - which is basically, similar to vvvv, that one should favour lists over iterations - it's a simple, consistent and logical environment.
Architect, the modular MIDI toolkit, beta now available for macOS, Windows, and Linux.
-
- KVRian
- 853 posts since 3 Nov, 2006 from Poland
I now love you and hate you at the same time Colin It sounds great! As it is looking great for all this time 
!
It sounds great! As it is looking great for all this time !
-
- KVRAF
- 2162 posts since 10 Mar, 2006
bungle wrote:Inefficient, Seriously ? any more optimising and it will be feeding CPU cycles back to the CPU haha
After a concert/gig you turn around and notice that your computer has become self aware and upgraded itself to have 100 CPUs each with a 100 cores. And looks like this:
"The educated person is one who knows how to find out what he does not know" - George Simmel
“It's what you learn after you know it all that counts.” - John Wooden
“It's what you learn after you know it all that counts.” - John Wooden
-
- KVRian
- 639 posts since 10 Jan, 2008
actually he is a plumber with coding abilities.
when it gets dark he tears his overall and turns into
NightCoder [tm]
like creating complex pipe systems he's wiring modules with his bare brain cells, to infinity - and beyond!
when it gets dark he tears his overall and turns into
NightCoder [tm]
like creating complex pipe systems he's wiring modules with his bare brain cells, to infinity - and beyond!
-
- KVRAF
- 7540 posts since 7 Aug, 2003 from San Francisco Bay Area
Colin- thank you for the detailed update. I, for one, appreciate hearing about what specifically you're working on. It is far better than the vagaries of "I'm working on it", month after month. I've written my fair share of messaging schemes, but never for a realtime environment. I'm sure that what you're doing is essential, and it sounds like a much more efficient approach.
Incomplete list of my gear: 1/8" audio input jack.
-
- KVRAF
- 2681 posts since 25 Aug, 2003 from Bournemouth, UK
It's my "main" project, but I'm working on various other things too: updates for the Loomer products, as well as prototypes for forthcoming plug-ins. I have other pursuits both engineering based - (amateur game coder, electronics, learning new programming languages - I'm teaching myself Haskell at the moment), and - gotta keep the balance - lots of things away from the glow of monitors and soldering irons: I'm a (terrible) archer; a fairly decent runner; a capable pen and ink artist; I'm working on a few book ideas, etc.
I have a busy life, just not enough time to fit it all in. If anyone has an inkling at how to build one of those devices that Michael Keaton uses in Multiplicity, I'm all ears.
I have a busy life, just not enough time to fit it all in. If anyone has an inkling at how to build one of those devices that Michael Keaton uses in Multiplicity, I'm all ears.
Architect, the modular MIDI toolkit, beta now available for macOS, Windows, and Linux.
-
- KVRAF
- 2357 posts since 24 Nov, 2012
ha ha - I know this lifecolin@loomer wrote:It's my "main" project, but I'm working on various other things too: updates for the Loomer products, as well as prototypes for forthcoming plug-ins. I have other pursuits both engineering based - (amateur game coder, electronics, learning new programming languages - I'm teaching myself Haskell at the moment), and - gotta keep the balance - lots of things away from the glow of monitors and soldering irons: I'm a (terrible) archer; a fairly decent runner; a capable pen and ink artist; I'm working on a few book ideas, etc.
I have a busy life, just not enough time to fit it all in. If anyone has an inkling at how to build one of those devices that Michael Keaton uses in Multiplicity, I'm all ears.
