Name - Price - Release date
Come on, we're not little kids here, and we're not waiting for Santa.
(the product formerly known as) Epoch
-
- Banned
- 454 posts since 30 Apr, 2013
-
- KVRAF
- 2678 posts since 25 Aug, 2003 from Bournemouth, UK
Noted; I need to tweak some things first, but I'll get a pic of this for the next teaser shot.jowen wrote:Collin posted a picture of a sequencer UI, it also would be nice to see a picture from the module with its in and outs?
Architect, the modular MIDI toolkit, beta now available for macOS, Windows, and Linux.
-
- KVRian
- Topic Starter
- 1177 posts since 2 Nov, 2006
3 years 3 months....and losing the will to .....hang.....on.................any......................lon.........ger................Col...........................................in...........
-
- KVRAF
- 2357 posts since 24 Nov, 2012
ha ha - it really is excruciating going back over the thread from all those years ago. The hopes, the excitement ....pinki wrote:3 years 3 months....and losing the will to .....hang.....on.................any......................lon.........ger................Col...........................................in...........
I'm still really looking forward to Epoch being released though
-
- KVRAF
- 2678 posts since 25 Aug, 2003 from Bournemouth, UK
It's unfortunately been a fairly unproductive past few days. I discovered an issue whilst testing how the lua scripting communicates with the module graph, which end up costing lots of hours, sleep, and sanity, to fix. But it is fixed now and I certainly hope that that'll be the last bug of this magnitude that sneaks in.
Basically, the goal is that nothing stops, halts, or stalls the audio and midi generation. Which poses particular problems with the lua scripting because it works in real-time, ie, whilst your patch is playing you can open up a scripting module, edit your code, hit compile, and it'll seamlessly switch over to the new script: essential for live coding.
So, bug nailed; back to finishing the UI and documenting the 200-some built-in modules. And this figure doesn't include the factory macros or scripts. What a way to spend a bank holiday.
Hope everyone else has a great bank holiday weekend too!
Basically, the goal is that nothing stops, halts, or stalls the audio and midi generation. Which poses particular problems with the lua scripting because it works in real-time, ie, whilst your patch is playing you can open up a scripting module, edit your code, hit compile, and it'll seamlessly switch over to the new script: essential for live coding.
So, bug nailed; back to finishing the UI and documenting the 200-some built-in modules. And this figure doesn't include the factory macros or scripts. What a way to spend a bank holiday.
Hope everyone else has a great bank holiday weekend too!
Architect, the modular MIDI toolkit, beta now available for macOS, Windows, and Linux.
-
- KVRAF
- 2194 posts since 18 Mar, 2006 from Plymouth, UK
-
- KVRAF
- 2194 posts since 18 Mar, 2006 from Plymouth, UK
Mine's gone now... but there's always next year. I mean, it can't possibly take *another* twelve months, right ?woggle wrote:My birthday is coming soon.
"by woggle; Sun May 11, 2014 11:09 pm
"-
- KVRAF
- 2678 posts since 25 Aug, 2003 from Bournemouth, UK
Sorry koalaboy; I was hoping yours was a late May rather then early May birthday!
It's been a productive week though, albeit one spent mainly bug fixing, polishing, and building example patches. As a proof of concept, I've been building some more impressive examples which demonstrate how easily complex programming tasks can be solved. One such test is a simple bouncing ball physics engine using an XY pad, which only uses about twenty-ish modules. I think it'd be easy to extend this into Pong using a couple of vertical slider components, but I'll leave that as an exercise for the intrepid patch builders amongst you!
I don't think I've spoken about the Array and Variable modules before, so perhaps it's time to introduce them. These modules allow you to store one value (in the Variable module) or a collection of values (in the Array module). We have corresponding read and write modules allowing one to store and retrieve values from connected modules. Actually, there are two read modules - Read Before and Read After, and two write modules - Write Before and Write After. It may seem strange having two reads and write modules, but these allow you to ensure that reads and writes occur at specific points relative to one another. Sometime you'll need to read before a write; other times, you'll need to write before a read.
For example, a simple counter may have a Read Before flowing into a Variable, and a Write After flowing from it. The value taken from Read Before will be incremented (with Add and Constant modules) and written back into the variable with the Write After module. If you wanted to also implement a reset, you could use a 2:1 switch to decide the input to the write module, so that the Write After can either store the incremented value we've read or store a default value instead.
A good example of how arrays can be used is the case of a simple 8 step sequencer patch. I have 8 pitch rotaries, each set with a range of 0 to 127, and quantised to integers. I also have 8 velocity rotaries, again, going from 0 to 127. We have two Arrays, Pitch and Velocity, both set to a size 8. Each pitch rotary goes to a Write Before module, using the module's Index input to specify the array location into which we will write this value. So rotary Pitch 1 goes to Array[0]; Pitch 2 to Array[1], etc. And the same with the Velocity rotaties, although this time storing into the Velocity array.
So that deals with the writing; reading the values back is even more straight-forward. A 1/8 Clock module triggers a Counter, of which we modulo the output with 8 to give us a continual 0, 1, 2, 3, 4, 5, 6, 7, 0 , 1, 2, 3... sequence. This value is connected to the Index of two Read After modules, one of which reads the Pitch array, the other the Velocity array. Finally, we use these values to generate MIDI notes using a Pack Note module. Simple!
(As an aside, one can live without the Variable module by using feedback, although the Variable module generally produces clearer patches.)
I've also been working on some debugging aids, including a display which shows which order the module graph is processed. This has proven very helpful on some more complex generative patches, I can assure you!
It's been a productive week though, albeit one spent mainly bug fixing, polishing, and building example patches. As a proof of concept, I've been building some more impressive examples which demonstrate how easily complex programming tasks can be solved. One such test is a simple bouncing ball physics engine using an XY pad, which only uses about twenty-ish modules. I think it'd be easy to extend this into Pong using a couple of vertical slider components, but I'll leave that as an exercise for the intrepid patch builders amongst you!
I don't think I've spoken about the Array and Variable modules before, so perhaps it's time to introduce them. These modules allow you to store one value (in the Variable module) or a collection of values (in the Array module). We have corresponding read and write modules allowing one to store and retrieve values from connected modules. Actually, there are two read modules - Read Before and Read After, and two write modules - Write Before and Write After. It may seem strange having two reads and write modules, but these allow you to ensure that reads and writes occur at specific points relative to one another. Sometime you'll need to read before a write; other times, you'll need to write before a read.
For example, a simple counter may have a Read Before flowing into a Variable, and a Write After flowing from it. The value taken from Read Before will be incremented (with Add and Constant modules) and written back into the variable with the Write After module. If you wanted to also implement a reset, you could use a 2:1 switch to decide the input to the write module, so that the Write After can either store the incremented value we've read or store a default value instead.
A good example of how arrays can be used is the case of a simple 8 step sequencer patch. I have 8 pitch rotaries, each set with a range of 0 to 127, and quantised to integers. I also have 8 velocity rotaries, again, going from 0 to 127. We have two Arrays, Pitch and Velocity, both set to a size 8. Each pitch rotary goes to a Write Before module, using the module's Index input to specify the array location into which we will write this value. So rotary Pitch 1 goes to Array[0]; Pitch 2 to Array[1], etc. And the same with the Velocity rotaties, although this time storing into the Velocity array.
So that deals with the writing; reading the values back is even more straight-forward. A 1/8 Clock module triggers a Counter, of which we modulo the output with 8 to give us a continual 0, 1, 2, 3, 4, 5, 6, 7, 0 , 1, 2, 3... sequence. This value is connected to the Index of two Read After modules, one of which reads the Pitch array, the other the Velocity array. Finally, we use these values to generate MIDI notes using a Pack Note module. Simple!
(As an aside, one can live without the Variable module by using feedback, although the Variable module generally produces clearer patches.)
I've also been working on some debugging aids, including a display which shows which order the module graph is processed. This has proven very helpful on some more complex generative patches, I can assure you!
Architect, the modular MIDI toolkit, beta now available for macOS, Windows, and Linux.
-
- KVRist
- 88 posts since 9 Dec, 2012
Colin wrote:
a display which shows which order the module graph is processed
are there displays that show the exact values at some selectable points with in patches?
a display which shows which order the module graph is processed
are there displays that show the exact values at some selectable points with in patches?
Located in the European Outback
