famusvictim
2013-05-30 07:12:40
Hi Florian,
Thanks for the tips and I'm glad you liked the BPM idea!
1)
Here's another idea I think would be absolutely incredible: Waveforms and Curves... the other kind that we all love - mathematical change over time, assignable to an ongoing MIDI output, or to create powerful global/local variables within a project:
(Sorry bout the CAPS, but by the time I caught myself, the damage was done and I wouldn't retype.)
NEW IDEA: A SET OF AVAILABLE PRESETS (such as in a dropdown menu) FOR VARIABLE CHANGE CURVES AND WAVEFORMS FOR ANY ONGOING MIDI MESSAGE OUTPUT, OR GLOBAL/LOCAL VARIABLES, FROM LINEAR TO "S" CURVE, TO PARABOLIC AND ASYMPTOTIC, TO WAVEFORM BASED, FROM PULSE WAVES TO SINE WAVES..... WHOSE PARAMETERS (SHAPES AND DURATIONS) CAN BE PROGRAMMED TO CHANGE WITH EITHER REALTIME USER INPUT, PRE-PROGRAMMING, OR BOTH.
These curves could either simply control output of a message over time from the point of being triggered, OR serve as realtime "power global/local variables", allowing a local variable to introduce change over time to other recruiting variable messages and create more dynamic translators and presets, or liven up entire projects with global change-over-time variables.
This would be incredibly useful to me, and I'm sure many other users from every MIDI industry, who want to introduce change over time to their MIDI messages that follow the familiar curves that we are already well acquainted with. Furthermore, to give the user control over the shape of a curve (the slope of a line, the intensity of an S Shape, the shape of a parabola, the width of a pulse wave) with either pre-programmed static, reliable and predictable change, OR realtime user controlled change, would just be mother***king awesome!!!
IF you like the idea. I would imagine that this should also be somehow easily integrated by the user to interact with any new BPM features you offer.
2)
I guess this would also imply another new feature: Ongoing output messages AND ongoing varying global/local variables, from the time of triggering with the former, or by creating a constant ongoing subroutine for the latter.
Here are three more:
3)
a built in feature to determine and insert mouse coordinates, for example, like the free program CursorCoordinates, among others. Perhaps even have it directly linked to the coordinate fields of the mouse output section of the translator, so the user would just point, and click a key command to fill in the field.
4)
A built in "decimal and message type" to hex translator... again, perhaps directly linked to the fields for input and output, as well as the rule window. I would have a translator with multiple fields for NON-sysex messages.
Semantic Message Name to HEX: Have one field for channel with a drop down menu, another drop-down menu field for message type, a third field should be an automatically generated title for the third byte variable type, and then a simple number entry from 0-127. Then have a "Convert and Insert At Cursor" button, for allowing insertion anywhere in the translator where the user clicks the cursor.
5) Compile a database of all publicly available SysEx libraries you can for enhanced SysEx functionality and ease of use for MT. Perhaps three drop down menus: Company, Product, and Message type, with control over any variable information.
This would perhaps be most easily achieved through corporate and friendly negotiations with manufacturers and software development companies, with the clear opportunity that having their blessing would give them should the program rise to become a go-to pro utility among studios, theater, pyrotechnicians, etc... IF you could actually get a few high rollers in the MIDI world to hop on, like Roland and Korg, then your leverage with other companies would snowball. You could offer increased SYSEX support in MT by helping users know what they're doing with their specific product, because currently MT and sysex is a trial an error process, and it doesn't need to be. Plus, the database would be text, and wouldn't be engaged as a processing burden, making it a incredible low burden on both MT's increased drive space, and zero processing burden, and thus no program slow-down issues.
If this is an option, then having a database of ALL MIDI implementation charts you can get is clearly a simultaneously necessary goal. As far as I know, NOBODY has a program with such a library, most likely because of licensing to products like Ableton that only can have support for products that want to be licensed for Ableton, but MT is very different from all other MIDI support programs, because it neither explicitly nor implicitly gives an advantage to any type of company, nor is geared towards any specific industry. It is even more "neutral" than Cycling 74... MT is the "Ultimate ANY-MIDI all-purose Utility" and is completely neutral, even implicitly. That is what makes me think it's worth a try - companies have nothing to loose, and only something to gain.
6)
In the same vein as #5, you could also work with companies to create a database of Key Commands, for another three drop-down menu easy entry..... company-->product-->KeyCommand
#5 and #6 might be more far-off goals, but I hope that 1-4 are practical, as they would be uber helpful.
Thanks for the tips and I'm glad you liked the BPM idea!
1)
Here's another idea I think would be absolutely incredible: Waveforms and Curves... the other kind that we all love - mathematical change over time, assignable to an ongoing MIDI output, or to create powerful global/local variables within a project:
(Sorry bout the CAPS, but by the time I caught myself, the damage was done and I wouldn't retype.)
NEW IDEA: A SET OF AVAILABLE PRESETS (such as in a dropdown menu) FOR VARIABLE CHANGE CURVES AND WAVEFORMS FOR ANY ONGOING MIDI MESSAGE OUTPUT, OR GLOBAL/LOCAL VARIABLES, FROM LINEAR TO "S" CURVE, TO PARABOLIC AND ASYMPTOTIC, TO WAVEFORM BASED, FROM PULSE WAVES TO SINE WAVES..... WHOSE PARAMETERS (SHAPES AND DURATIONS) CAN BE PROGRAMMED TO CHANGE WITH EITHER REALTIME USER INPUT, PRE-PROGRAMMING, OR BOTH.
These curves could either simply control output of a message over time from the point of being triggered, OR serve as realtime "power global/local variables", allowing a local variable to introduce change over time to other recruiting variable messages and create more dynamic translators and presets, or liven up entire projects with global change-over-time variables.
This would be incredibly useful to me, and I'm sure many other users from every MIDI industry, who want to introduce change over time to their MIDI messages that follow the familiar curves that we are already well acquainted with. Furthermore, to give the user control over the shape of a curve (the slope of a line, the intensity of an S Shape, the shape of a parabola, the width of a pulse wave) with either pre-programmed static, reliable and predictable change, OR realtime user controlled change, would just be mother***king awesome!!!
IF you like the idea. I would imagine that this should also be somehow easily integrated by the user to interact with any new BPM features you offer.
2)
I guess this would also imply another new feature: Ongoing output messages AND ongoing varying global/local variables, from the time of triggering with the former, or by creating a constant ongoing subroutine for the latter.
Here are three more:
3)
a built in feature to determine and insert mouse coordinates, for example, like the free program CursorCoordinates, among others. Perhaps even have it directly linked to the coordinate fields of the mouse output section of the translator, so the user would just point, and click a key command to fill in the field.
4)
A built in "decimal and message type" to hex translator... again, perhaps directly linked to the fields for input and output, as well as the rule window. I would have a translator with multiple fields for NON-sysex messages.
Semantic Message Name to HEX: Have one field for channel with a drop down menu, another drop-down menu field for message type, a third field should be an automatically generated title for the third byte variable type, and then a simple number entry from 0-127. Then have a "Convert and Insert At Cursor" button, for allowing insertion anywhere in the translator where the user clicks the cursor.
5) Compile a database of all publicly available SysEx libraries you can for enhanced SysEx functionality and ease of use for MT. Perhaps three drop down menus: Company, Product, and Message type, with control over any variable information.
This would perhaps be most easily achieved through corporate and friendly negotiations with manufacturers and software development companies, with the clear opportunity that having their blessing would give them should the program rise to become a go-to pro utility among studios, theater, pyrotechnicians, etc... IF you could actually get a few high rollers in the MIDI world to hop on, like Roland and Korg, then your leverage with other companies would snowball. You could offer increased SYSEX support in MT by helping users know what they're doing with their specific product, because currently MT and sysex is a trial an error process, and it doesn't need to be. Plus, the database would be text, and wouldn't be engaged as a processing burden, making it a incredible low burden on both MT's increased drive space, and zero processing burden, and thus no program slow-down issues.
If this is an option, then having a database of ALL MIDI implementation charts you can get is clearly a simultaneously necessary goal. As far as I know, NOBODY has a program with such a library, most likely because of licensing to products like Ableton that only can have support for products that want to be licensed for Ableton, but MT is very different from all other MIDI support programs, because it neither explicitly nor implicitly gives an advantage to any type of company, nor is geared towards any specific industry. It is even more "neutral" than Cycling 74... MT is the "Ultimate ANY-MIDI all-purose Utility" and is completely neutral, even implicitly. That is what makes me think it's worth a try - companies have nothing to loose, and only something to gain.
6)
In the same vein as #5, you could also work with companies to create a database of Key Commands, for another three drop-down menu easy entry..... company-->product-->KeyCommand
#5 and #6 might be more far-off goals, but I hope that 1-4 are practical, as they would be uber helpful.