will it be possible to mute a parameter? also if you have a container that has only parameters present, no figures, if you mute it, will it mute those paramter changes?
Not individually, but yes, you can mute a container with any parameters in it and they'll be ignored.
On a general note, in addition to new features, version 2 will unleash a lot of power that was previously present already, but inconvenient to access or difficult to understand.
This is so completely mindblowing, I'm missing the right words. KIM is different from every programming language I have used so far.
Looking forward to hearing what the KIM scripting language can do for generating my own material or creating the ever-changing "best of" of my pre-existing phrases.
I can hardly await the first release of Synfire 2.0.
If it's a Kitbash approach to music, with KIM smoothing the edges, sounds good to me. I note that it will also permutate the Kitbash components. The key for me though is the ability to manage the data of the song, such that I can go in and change an element, and have Kim ripple it out across the song.
What you have done with 2.0 is simply amazing. I have a feeling that this is going to be a real game changer for everyone that is using Synfire. Please include me in the desire to beta test. I am so grateful for you and your unending effort to improve this wonderful product. There's nothing like Synfire on the market.
Some community driven development would be absolutely great (on the long term to do list already), but KIM sources can't be compiled or tested in isolation. It literally lives inside Synfire's data structures. After all the rules-based magic is done, it invokes Synfire functions on a phrase.
For a language to become mature, much thought needs to be spent on naming conventions and how to organize a code base (KIM factories) and optimize it for maximum modularity. This is an evolutionary process that takes time. I've streamlined the thing like five times already and it's still in motion. It's inevitable that KIM will not yet be mature with Synfire 2.0.
KIM is a kind of "modular synth" that generates parameters and phrases and populates containers. Each module is a KIM Factory that takes other factories for input. In theory, an entire song could be assembled from factories, but that would get deep and confusing very quickly.
Imagine each factory potentially expands to millions of outputs (based on your settings and its stochastic variables). Then you'd branch into the inputs, each again with millions of outputs, and so forth. For an average song, you'd have more final outputs than there are particles in the universe. This vast combinatorial space is impossible to control with sliders and check boxes in any meaningful way, unless you want to spend the rest of your life navigating a deeply nested user interface.
That's why Synfire encourages you to create lots of smaller building blocks incrementally and assemble them in different ways: Bass lines, chord stabs, arpeggiators, melodies, counterpoint melodies, build-ups, licks, soli, minimalist patterns, etc. Even stuff that doesn't yet have a name.
Although all Synfire users will start with the same factories, everyone will gather their own personal libraries of building blocks that will set their music apart from others.
As someone who has been coding in the field of rule-based algorithmic composition for many years, I would very much like to learn more about KIM. I applaud your overall direction to combine algorithmic generation/transformation (in a way that seemingly already implements concepts of musical form), manual selection of resulting building blocks and then controlling the overall result also manually. Very interesting what you shared so far!
Do you plan to allow users to implement their own building blocks (factories?) and perhaps to already do that in the upcoming version 2.0, regardless how mature KIM already is?
If I remember correctly, Synfire is implemented in Smalltalk, but this language looks like a domain specific language with its own syntax etc., right? Do you plan to share some documentation of this language like a tutorial and/or a reference?
Again, great to see this development! I recently celebrated my birthday -- this is a bit like a voucher for a nice gift to get a bit later ;-)
KIM factories are deeply configurable to produce a wide variety of phrases and musical expressions. Generated phrases remember all KIM settings, so each generated phrase pool basically is a factory in itself. This means you can make new factories by re-configuring existing ones, without writing a single line of code. That's what we envisioned for 2.0.
As for coding, there's only rudementary documentation yet and the current IDE runs within our development environment only. You'd also need some deep introductory prose to even get started. We hardly have enough time to complete the new Synfire documentation and videos, so that is really out of the question for 2.0. Let's see how this evolves.
Thanks for your response. We are all looking forward to what is already planned to be included in the update. User-coding support would likely only cater for a small slice of your user base, so it makes completely sense that this is not a priority.
> each generated phrase pool basically is a factory in itself
Wow, that could be very interesting for creating variations etc!
Is it possible (to make)
1. To combine instrument tracks into a folder track?.
2. And to make (a selection of) tracks invisible?
3. Give instrument tracks their own color?
That would be very helpful when working with large orchestral scores.
As possible in Cubase for example.
Yes, but that software is not maintained anymore, sorry. If you are looking for something similar, I would recommend Cluster Engine by Örjan Sandred. However, this is only something for geeks – not comparable with Synfire.
In a way, yes. You'd use containers where you minimize the instruments you're not interested in. So if the string section is doing something important for the narrative, place a container (with a specific color and label) an put all the string phrases in there.
The thing is, there's actually no "track" per instrument in Synfire where you'd have phrases over the course of the entire song. That would make it very hard to change things at a higher level. Things would be set in stone early on and that totally defeats the idea of prototyping.
By the way, Logic X has containers too (not sure if it's still the case), but since it's all static MIDI, moving them around is of very limited use.
The new 'Overview' page is actually a virtual track sheet, i.e. a different perspective that shows which containers each instrument is influenced by over the course of the song. It is more like a navigation map however. Once you double-click on an object, it will take you to the same place on the 'Containers' page. Using the new '<' and '>' buttons, you can switch back and forth between them.
Andre, what do you call a guy who can write elaborate prose about how wonderful his program is but is too busy to answer ONE support ticket from a guy who spent 1,000 DOLLARS on his software?
Due to current workload, it may take 2-3 days to respond to requests (same for forum posts, we don't have a system that reminds us of open tickets). If something seems to have slipped our attention, don't hesitate to follow up on it by mail.
Could you share some more info on how it will roll out?
It's all bug fixing and streamlining at the moment. Documentation, packaging and deployment however have yet to be addressed (installation, migration from version 1, handling of license upgrades, fine tuning for the Windows platform, etc). This administrative tech is no small part. Doing it right is essential.
In other words, Synfire 2.0 doesn't even install yet. It merely runs in our development environment. So, while the code is essentially complete, there's no way to provide a download (beta or not) anytime soon.
Things are slowly coming to a close, but it might still take the better part of October to get everything done.
Thats not a nice way to say, "Andre, in case you missed my inquiry about your program in this thread [or in a support ticket] that I'm very eager to have an answer to; I wanted to know ... "
I don't mean to butt in, but respect goes a long way.
There have been issues in the past with the Windows 8 installer, but apart from that, I don't yet see why Synfire shouldn't run. I can't make a promise, though. Should unforseen obstacles come up, we might need to update the system requirement.
Same for macOS. We are currently at 10.10, but may possibly need to update the minimum requirement to 10.11.
Pricing is not yet final. Licenses purchased starting April 2019 can upgrade for free. Upgrades from Synfire 1 will be moderate (no more than 20% of full price, equivalent to an 80% discount).
In order for this long thread to stay focussed, please open a new thread for discussions not related to software features. Thanks.
An update on system requirements:
Windows 11 will launch next week. Windows 10 was released six years ago and will be supported another four. The considerable effort to support soon-to-be obsolete Windows 8.1 is hard to justify at this point.
For example, among other things, HiDPI support on Windows is a pain in the butt and waste of time for developers, compared to Apple's DPI-agnostic system. Things got a little better with Windows 10. Therefore, like all major music software releases, we now decided for Synfire 2.0 to require Windows 10 or later.
As we are at it: In order to avoid further delays, HiDPI support might not be available until a 2.x update. Until then, you'll be able to make music with 2.0, based on the current graphics resolution.
Buy a cheap windows 10 pro key and install it as a boot on a sdd.
Its always handy to reserve your operatingsystem for one disk and install all other on another disks
Make the chance and the plunge to modern times : -)
Hi Andre, with Synfire 2.0 please add the iLock cloud activation option. VSL is also moving soon to iLock with a cloud activation option. I would really like to not have to carry around a dongle.
Comments
Tue, 2021-08-10 - 16:57 Permalink
Oh, and editable keyboard shortcuts, finally. Exportable as HTML so you can print a cheat sheet.
Tue, 2021-08-10 - 17:47 Permalink
will it be possible to mute a parameter? also if you have a container that has only parameters present, no figures, if you mute it, will it mute those paramter changes?
Tue, 2021-08-10 - 20:40 Permalink
This keeps getting better and better... can't hide my excitement about the upcoming Synfire 2.
Thu, 2021-08-12 - 08:21 Permalink
Not individually, but yes, you can mute a container with any parameters in it and they'll be ignored.
On a general note, in addition to new features, version 2 will unleash a lot of power that was previously present already, but inconvenient to access or difficult to understand.
Thu, 2021-08-12 - 16:22 Permalink
absolutely stellar!
Thu, 2021-08-12 - 16:22 Permalink
amazing
Thu, 2021-08-12 - 16:23 Permalink
fantastic
Thu, 2021-08-12 - 16:33 Permalink
Superlative! Way beyond wildest expectations! Cannot wait!
Sun, 2021-08-15 - 16:40 Permalink
This is excellent Andre.
Tue, 2021-08-31 - 13:17 Permalink
This is so completely mindblowing, I'm missing the right words. KIM is different from every programming language I have used so far.
Looking forward to hearing what the KIM scripting language can do for generating my own material or creating the ever-changing "best of" of my pre-existing phrases.
I can hardly await the first release of Synfire 2.0.
Tue, 2021-08-31 - 15:21 Permalink
Beta release in days:
T-30
;)
Tue, 2021-08-31 - 16:50 Permalink
If it's a Kitbash approach to music, with KIM smoothing the edges, sounds good to me. I note that it will also permutate the Kitbash components. The key for me though is the ability to manage the data of the song, such that I can go in and change an element, and have Kim ripple it out across the song.
Tue, 2021-08-31 - 17:32 Permalink
Hi Andre
What you have done with 2.0 is simply amazing. I have a feeling that this is going to be a real game changer for everyone that is using Synfire. Please include me in the desire to beta test. I am so grateful for you and your unending effort to improve this wonderful product. There's nothing like Synfire on the market.
Tue, 2021-08-31 - 19:52 Permalink
+1 for the Beta test. Thanks
Tue, 2021-08-31 - 20:07 Permalink
Likewise...sign me up for the Beta!
Wed, 2021-09-01 - 03:14 Permalink
lmao sorry Andre I posted about being in the beta when there isnt a beta and now everyone wants to be in the beta. My bad :)
Wed, 2021-09-01 - 17:15 Permalink
Yup...you really got my hopes up, and now they are dashed. Dang. :)
But I'm eagerly anticipating the new Synfire, in whatever form.
Wed, 2021-09-01 - 21:20 Permalink
The KIM concept is going to be exciting for a lot of people, including me. This will really expand the possibilities of Synfire exponentially
Wed, 2021-09-01 - 21:39 Permalink
Have you thought about making KIM's source code available? It sounds like a lot of work to maintain.
Sat, 2021-09-04 - 11:31 Permalink
Some community driven development would be absolutely great (on the long term to do list already), but KIM sources can't be compiled or tested in isolation. It literally lives inside Synfire's data structures. After all the rules-based magic is done, it invokes Synfire functions on a phrase.
For a language to become mature, much thought needs to be spent on naming conventions and how to organize a code base (KIM factories) and optimize it for maximum modularity. This is an evolutionary process that takes time. I've streamlined the thing like five times already and it's still in motion. It's inevitable that KIM will not yet be mature with Synfire 2.0.
It will do mind blowing stuff nevertheless.
Mon, 2021-09-06 - 08:12 Permalink
The big picture:
KIM is a kind of "modular synth" that generates parameters and phrases and populates containers. Each module is a KIM Factory that takes other factories for input. In theory, an entire song could be assembled from factories, but that would get deep and confusing very quickly.
Imagine each factory potentially expands to millions of outputs (based on your settings and its stochastic variables). Then you'd branch into the inputs, each again with millions of outputs, and so forth. For an average song, you'd have more final outputs than there are particles in the universe. This vast combinatorial space is impossible to control with sliders and check boxes in any meaningful way, unless you want to spend the rest of your life navigating a deeply nested user interface.
That's why Synfire encourages you to create lots of smaller building blocks incrementally and assemble them in different ways: Bass lines, chord stabs, arpeggiators, melodies, counterpoint melodies, build-ups, licks, soli, minimalist patterns, etc. Even stuff that doesn't yet have a name.
Although all Synfire users will start with the same factories, everyone will gather their own personal libraries of building blocks that will set their music apart from others.
Tue, 2021-09-07 - 15:42 Permalink
As someone who has been coding in the field of rule-based algorithmic composition for many years, I would very much like to learn more about KIM. I applaud your overall direction to combine algorithmic generation/transformation (in a way that seemingly already implements concepts of musical form), manual selection of resulting building blocks and then controlling the overall result also manually. Very interesting what you shared so far!
Do you plan to allow users to implement their own building blocks (factories?) and perhaps to already do that in the upcoming version 2.0, regardless how mature KIM already is?
If I remember correctly, Synfire is implemented in Smalltalk, but this language looks like a domain specific language with its own syntax etc., right? Do you plan to share some documentation of this language like a tutorial and/or a reference?
Again, great to see this development! I recently celebrated my birthday -- this is a bit like a voucher for a nice gift to get a bit later ;-)
Thu, 2021-09-09 - 09:19 Permalink
KIM factories are deeply configurable to produce a wide variety of phrases and musical expressions. Generated phrases remember all KIM settings, so each generated phrase pool basically is a factory in itself. This means you can make new factories by re-configuring existing ones, without writing a single line of code. That's what we envisioned for 2.0.
As for coding, there's only rudementary documentation yet and the current IDE runs within our development environment only. You'd also need some deep introductory prose to even get started. We hardly have enough time to complete the new Synfire documentation and videos, so that is really out of the question for 2.0. Let's see how this evolves.
Fri, 2021-09-10 - 09:24 Permalink
Thanks for your response. We are all looking forward to what is already planned to be included in the update. User-coding support would likely only cater for a small slice of your user base, so it makes completely sense that this is not a priority.
> each generated phrase pool basically is a factory in itself
Wow, that could be very interesting for creating variations etc!
Fri, 2021-09-10 - 15:05 Permalink
tanders, are you the creator of Strasheela?
Sat, 2021-09-11 - 15:35 Permalink
Sure. Looking forward for it.
Sat, 2021-09-11 - 18:39 Permalink
Organizing instrument tracks.
Is it possible (to make)
1. To combine instrument tracks into a folder track?.
2. And to make (a selection of) tracks invisible?
3. Give instrument tracks their own color?
That would be very helpful when working with large orchestral scores.
As possible in Cubase for example.
Mon, 2021-09-13 - 19:41 Permalink
> are you the creator of Strasheela?
Yes, but that software is not maintained anymore, sorry. If you are looking for something similar, I would recommend Cluster Engine by Örjan Sandred. However, this is only something for geeks – not comparable with Synfire.
Tue, 2021-09-14 - 08:16 Permalink
In a way, yes. You'd use containers where you minimize the instruments you're not interested in. So if the string section is doing something important for the narrative, place a container (with a specific color and label) an put all the string phrases in there.
The thing is, there's actually no "track" per instrument in Synfire where you'd have phrases over the course of the entire song. That would make it very hard to change things at a higher level. Things would be set in stone early on and that totally defeats the idea of prototyping.
By the way, Logic X has containers too (not sure if it's still the case), but since it's all static MIDI, moving them around is of very limited use.
The new 'Overview' page is actually a virtual track sheet, i.e. a different perspective that shows which containers each instrument is influenced by over the course of the song. It is more like a navigation map however. Once you double-click on an object, it will take you to the same place on the 'Containers' page. Using the new '<' and '>' buttons, you can switch back and forth between them.
Thu, 2021-09-16 - 16:10 Permalink
Andre, you mentioned October, right?...
Could you share some more info on how it will roll out?
Alpha/Beta testing for registered v1 Synfire owners, upgrade policy, and dates for availability...
Cheers,
Carlos
Fri, 2021-09-17 - 01:48 Permalink
Andre, what do you call a guy who can write elaborate prose about how wonderful his program is but is too busy to answer ONE support ticket from a guy who spent 1,000 DOLLARS on his software?
Fri, 2021-09-17 - 08:37 Permalink
Due to current workload, it may take 2-3 days to respond to requests (same for forum posts, we don't have a system that reminds us of open tickets). If something seems to have slipped our attention, don't hesitate to follow up on it by mail.
It's all bug fixing and streamlining at the moment. Documentation, packaging and deployment however have yet to be addressed (installation, migration from version 1, handling of license upgrades, fine tuning for the Windows platform, etc). This administrative tech is no small part. Doing it right is essential.
In other words, Synfire 2.0 doesn't even install yet. It merely runs in our development environment. So, while the code is essentially complete, there's no way to provide a download (beta or not) anytime soon.
Things are slowly coming to a close, but it might still take the better part of October to get everything done.
Fri, 2021-09-17 - 09:42 Permalink
Will Synfire 2.0 run on Windows 8?
Fri, 2021-09-17 - 18:08 Permalink
Thats not a nice way to say, "Andre, in case you missed my inquiry about your program in this thread [or in a support ticket] that I'm very eager to have an answer to; I wanted to know ... "
I don't mean to butt in, but respect goes a long way.
Fri, 2021-09-17 - 18:56 Permalink
That person has better could first ask to Andre why he has missed his sended e-mail to him?
Wed, 2021-09-22 - 20:44 Permalink
There have been issues in the past with the Windows 8 installer, but apart from that, I don't yet see why Synfire shouldn't run. I can't make a promise, though. Should unforseen obstacles come up, we might need to update the system requirement.
Same for macOS. We are currently at 10.10, but may possibly need to update the minimum requirement to 10.11.
Sat, 2021-09-25 - 21:57 Permalink
Will Synfire 2.0 run on Windows ARM?
Tue, 2021-09-28 - 13:40 Permalink
We don't have plans to support the Windows ARM platform at this time.
Possibly Microsoft offers some virtualization for running Intel code for backwards compatibility, I don't know.
Thu, 2021-09-30 - 01:31 Permalink
Any ballpark figure on the cost for people who already have a license? I need to budget for this ahead of time a bit I think.
Fri, 2021-10-01 - 11:43 Permalink
Pricing is not yet final. Licenses purchased starting April 2019 can upgrade for free. Upgrades from Synfire 1 will be moderate (no more than 20% of full price, equivalent to an 80% discount).
In order for this long thread to stay focussed, please open a new thread for discussions not related to software features. Thanks.
An update on system requirements:
Windows 11 will launch next week. Windows 10 was released six years ago and will be supported another four. The considerable effort to support soon-to-be obsolete Windows 8.1 is hard to justify at this point.
For example, among other things, HiDPI support on Windows is a pain in the butt and waste of time for developers, compared to Apple's DPI-agnostic system. Things got a little better with Windows 10. Therefore, like all major music software releases, we now decided for Synfire 2.0 to require Windows 10 or later.
As we are at it: In order to avoid further delays, HiDPI support might not be available until a 2.x update. Until then, you'll be able to make music with 2.0, based on the current graphics resolution.
Fri, 2021-10-01 - 15:56 Permalink
Andre Boss... Dont forgot, Black Friday 50% on this 20% ...
Fri, 2021-10-01 - 19:18 Permalink
I hope this is intended as a joke. Just saying...
Fri, 2021-10-01 - 19:26 Permalink
Me too.
20% of full price seems very reasonable. Synfire 2.0 is, after all, a MAJOR update.
Mon, 2021-10-04 - 23:59 Permalink
Thanks Andre that helps with budgeting!
Tue, 2021-10-05 - 07:42 Permalink
! Oh Yes Ofc ! this price is good for you and others here i think...but me i'm different.. lmaooo Andre know that...
Tue, 2021-10-05 - 09:11 Permalink
I'm totally fine with that price and willing to pay it.
If it just weren't for the Windows 10 requirement ("Never touch a running system"), will surely cope with that somehow.
Tue, 2021-10-05 - 11:29 Permalink
Support for Windows 8.1 ends in little over a year so it's time to upgrade anyway if you're not running W10 or, as of today, W11.
Tue, 2021-10-05 - 19:18 Permalink
Buy a cheap windows 10 pro key and install it as a boot on a sdd.
Its always handy to reserve your operatingsystem for one disk and install all other on another disks
Make the chance and the plunge to modern times : -)
today i got some advertising Goedkoop Microsoft Windows kopen? Directe levering (gamekeydiscounter.nl)
Fri, 2021-10-08 - 18:36 Permalink
Hello! Perhaps it is possible to have a demo of Synfire pro 2 when it realized for us how have a licens for Synfire pro 1.8 ?
Sun, 2021-10-10 - 17:51 Permalink
Hi Andre, with Synfire 2.0 please add the iLock cloud activation option. VSL is also moving soon to iLock with a cloud activation option. I would really like to not have to carry around a dongle.