Comments by JoeM
If you have any issues, please submit them to the GitHub project, I don't really use Max that much therefore barely come to this site.
I just re-uploaded it to Github.
My source for this is on a drive that I don't have access to but can get it (NAS issues).
In the meantime, I uploaded the last amxd I could find.
It's called 1.5, but I think this was actually the 2.0.
Follow this repo for more updates when I find the source files
https://github.com/JoeMatt/BassStationIIMaxForLive/
My source for this is on a drive that I don't have access to but can get it (NAS issues).
In the meantime, I uploaded the last amxd I could find.
It's called 1.5, but I think this was actually the 2.0.
Follow this repo for more updates when I find the source files
https://github.com/JoeMatt/BassStationIIMaxForLive/
I think possibly what's happening is that your Bass Stations are set with MIDI Remote In activated in Live's preferences. That means that Live will receive the CC messages that the hardware receives. Now if that's the case, and you have a track armed with "All Devices' as the input, then the CC messages that one bass station sends when you a control get routed through Live and into my patch and out to the other Bass Station.
The way around this is to select the specify BS for the track in the input devices, or only use the Router or CoreMIDI (if on Mac) modes.
The router is pre=programmed to a specific port number, so if you have two instances you'll have to open up the device in Max and change the port number to be unique per device, otherwise you'll have the same issue where 1 BS input is being routed to both Max devices.
The way around this is to select the specify BS for the track in the input devices, or only use the Router or CoreMIDI (if on Mac) modes.
The router is pre=programmed to a specific port number, so if you have two instances you'll have to open up the device in Max and change the port number to be unique per device, otherwise you'll have the same issue where 1 BS input is being routed to both Max devices.
re: Helder.
I had the same probably before noticing MIDI Echo was activated on my M1000. 'Ext Funct' -> #2 should read 'Eof'.
re: staplesyrup
I have a CoreMIDI device I've written myself and I've managed to successfully replace lh_midi within your patch. E-mail me at mail _at_ joemattiello.comand I can send it to you.
I had the same probably before noticing MIDI Echo was activated on my M1000. 'Ext Funct' -> #2 should read 'Eof'.
re: staplesyrup
I have a CoreMIDI device I've written myself and I've managed to successfully replace lh_midi within your patch. E-mail me at mail _at_ joemattiello.comand I can send it to you.
No manual as of yet. Maybe once I fix the bugs. With winter coming I'll be spending my time on projects again.
re: Random. Pretty simple. Sections with their locks locked won't change on random. Everything else will. Some parameters are never random because I found them to not respond musically very like, like oscillator detunes and some others. If you hack open the patch, the Javascript contained within has a human readable list of parameters with true/false values for whether they respond to random if you want to customize it further.
re: Random. Pretty simple. Sections with their locks locked won't change on random. Everything else will. Some parameters are never random because I found them to not respond musically very like, like oscillator detunes and some others. If you hack open the patch, the Javascript contained within has a human readable list of parameters with true/false values for whether they respond to random if you want to customize it further.
It should work on Windows with the router, but I don't have a box to test on. I've been swamped all summer with day job project, I plan on getting back into my Max patches once the long, dark, New York winter comes in.
2.0 version posted. I think all the previous issues with parameter naming are fixed.
2.0 has experimental, (but stable for me) support for a new native Max object to transport SYSEX/CC messages bidirectionally to the hardware without needing a router patch or, in the case of CCs, having to have the track armed for live UI updates.
Native routing is OS X only. In fact, i haven't even tried opening thison a Windows machine so I do hope it doesn't crash. External Max patch router is still support for Windows and Mac as previous versions.
The only planned features I have left are group random lock/unlock like I have in my Hawk-800 editor that I posted yesterday. As in previous version, random is pre-programmed to only effect the paramaters that are considered, to me at least, most musical. Therefor it doesn't change things like OSC tune modulation, noise volume, and some other parameters that are more than likely to result in patches that are considered more SFX that musical. If this really bothers you and you can't wait for the next release, it's trivial to change the allowed parameters. Simply open up the main JS(processcc.js)file in the cc subpatch and change the false values to true for the random parameter dictionaries.
2.0 has experimental, (but stable for me) support for a new native Max object to transport SYSEX/CC messages bidirectionally to the hardware without needing a router patch or, in the case of CCs, having to have the track armed for live UI updates.
Native routing is OS X only. In fact, i haven't even tried opening thison a Windows machine so I do hope it doesn't crash. External Max patch router is still support for Windows and Mac as previous versions.
The only planned features I have left are group random lock/unlock like I have in my Hawk-800 editor that I posted yesterday. As in previous version, random is pre-programmed to only effect the paramaters that are considered, to me at least, most musical. Therefor it doesn't change things like OSC tune modulation, noise volume, and some other parameters that are more than likely to result in patches that are considered more SFX that musical. If this really bothers you and you can't wait for the next release, it's trivial to change the allowed parameters. Simply open up the main JS(processcc.js)file in the cc subpatch and change the false values to true for the random parameter dictionaries.
Updated. Added test case so all verified to work now.
Nice find. I'll have an update shortly. Thanks.
Updated the patch to work with the new SYSEX format.
NEW VERSION COMING SOON
I have a new test version that works with SYSEX without needing to use a patch router. It will be Mac only at first since it requires a new external I wrote in C.
I'm currently testing and working on updating the UI to move the settings for this new feature and handeling of patches to a popup instead of cluttering up the panel.
Also will have a new custom UI elements for users who are using Max 7.
NEW VERSION COMING SOON
I have a new test version that works with SYSEX without needing to use a patch router. It will be Mac only at first since it requires a new external I wrote in C.
I'm currently testing and working on updating the UI to move the settings for this new feature and handeling of patches to a popup instead of cluttering up the panel.
Also will have a new custom UI elements for users who are using Max 7.
I managed to figure out what was wrong with my sysex importer, so I just did another quick update to 1.2 with that feature added.
Hey Frank,
Thanks for the feedback.
The new version 1.1 should fix the problem with "Speed in Beats" for both LFOs.
I also added a random feature. It's random for MOST parameters but not all. Things that would really make the patches unusable are locked to their current setting. Some examples,
- OSC tuning course and fine
- LFO to pitch
- Mod env to pitch
- OSC 1 mix amount (sub and 2 change)
- Noise, Ext, Ring mix amount
- LFO keysync
- Distortion
- OSC filter mod
- LFO slew
- others….
I think this makes the random feature more usable. I get good sounded patches almost any time.
As far as your idea for presets and morph.
You can save a snap shot of the patch into Live. Every parameter is a M4L native object to Ableton should save the current state. There are some M4L patches already available that can take snapshots of device states and morph between them.
It's unlikely that feature will be added inside this patch as it would be a lot of overhead to store the patch state separately.
I'm looking into the ability to load up and store SYSEX presets though so you can mange your patches as syses files, with possibly an browser in the patch. I'm waiting for feedback from the Max forum to fix a big I've had when I tried building this.
Thanks for the feedback.
The new version 1.1 should fix the problem with "Speed in Beats" for both LFOs.
I also added a random feature. It's random for MOST parameters but not all. Things that would really make the patches unusable are locked to their current setting. Some examples,
- OSC tuning course and fine
- LFO to pitch
- Mod env to pitch
- OSC 1 mix amount (sub and 2 change)
- Noise, Ext, Ring mix amount
- LFO keysync
- Distortion
- OSC filter mod
- LFO slew
- others….
I think this makes the random feature more usable. I get good sounded patches almost any time.
As far as your idea for presets and morph.
You can save a snap shot of the patch into Live. Every parameter is a M4L native object to Ableton should save the current state. There are some M4L patches already available that can take snapshots of device states and morph between them.
It's unlikely that feature will be added inside this patch as it would be a lot of overhead to store the patch state separately.
I'm looking into the ability to load up and store SYSEX presets though so you can mange your patches as syses files, with possibly an browser in the patch. I'm waiting for feedback from the Max forum to fix a big I've had when I tried building this.
Also, I plan on adding incoming CC control.
It's not difficult it's just a lot of stuff to wire up.
I should be able to easily add drag and drop .sysex patch files and maybe even a patch browser. As soon as I find the time.
It's not difficult it's just a lot of stuff to wire up.
I should be able to easily add drag and drop .sysex patch files and maybe even a patch browser. As soon as I find the time.
Hi,
Thanks, glad you like it.
I'm not sure what you mean by UI update? If you mean, "turn a knob on the bass station, see it on the device", that feature isn't in there yet.
The patch can decode incoming SYSEX patch dumps but it doesn't recognize all the Continuos Control messages. If you want the UI to reflect what the device's current settings are you need to use the router and request a patch dump using the button on the lower right of the "Bass Station" logo text.
To use the router:
1) Plug in Bass Station 2 via USB
2) Open the router. It should auto-select the Bass Station MIDI in and outs. If not, select them from the drop downs.
3) Open the M4L patch. It will auto connect.
Actually, technically the order of 2 & 3 don't even matter. They'll find each other as long as they're running. They connect using a local network, not any of Live's midi routing since it blocks SYSEX data. No extra settings are required on the Live side.
Thanks, glad you like it.
I'm not sure what you mean by UI update? If you mean, "turn a knob on the bass station, see it on the device", that feature isn't in there yet.
The patch can decode incoming SYSEX patch dumps but it doesn't recognize all the Continuos Control messages. If you want the UI to reflect what the device's current settings are you need to use the router and request a patch dump using the button on the lower right of the "Bass Station" logo text.
To use the router:
1) Plug in Bass Station 2 via USB
2) Open the router. It should auto-select the Bass Station MIDI in and outs. If not, select them from the drop downs.
3) Open the M4L patch. It will auto connect.
Actually, technically the order of 2 & 3 don't even matter. They'll find each other as long as they're running. They connect using a local network, not any of Live's midi routing since it blocks SYSEX data. No extra settings are required on the Live side.
I think this was the last version, let me know if there are issues.