Still don't understand it, sorry. Did you put the Sequence Player before or after the Note Dispatcher? And which Note Dispatcher mode did you select?magicmusic wrote:I like use sequences in latch(hold mode) (i use mux sequencer end is set to never), so the key need not press always. Now when switch to another sequence the old sequence always continue to play on mulab.
MuLab & MUX Modular 6.4.17 Released
-
- KVRAF
- Topic Starter
- 12740 posts since 24 Jun, 2008 from Europe
-
- KVRian
- 1371 posts since 11 Nov, 2013
The note dispatcher is before 2 sequence player. The mode i use is Key range. special key is set to c3 for easy test. so c3 select 1. output. c#3 select 2. output. I can send you the mulab song if you not know what i mean. what happen is this. i press for example c2 key and release, then sequence is play in loop. Then i wand play another sequence and press c#3. now 1. sequence continue to play and 2. sequence start, after i press a key.
but usefull is, when press c#3 1. sequence stop play and 2. sequence start play. Please let me know if you want the mulab song
but usefull is, when press c#3 1. sequence stop play and 2. sequence start play. Please let me know if you want the mulab song
win 10 64 22H2 intel i5 8600K (6*3.6 GHZ) 32 GB Ram
-
- KVRAF
- Topic Starter
- 12740 posts since 24 Jun, 2008 from Europe
Ok i understand your request. No need for the project file, thx. Will have to think about your request. At first thought i don't think this is related to the Note Dispatcher module as the note-off for your note-on has already been dispatched quite soon after the note-on as you just 'trigger' the sequence player, and so you are requesting to send an extra note-off for this specific case. I think this is rather about a new module or an extended mode of the Sequence Player, kind of Multi-Sequence Player. Can't do it in M6.4 anymore. Anyway, i do understand your request music-wise, would indeed great to have that functionality (as well as many other wishes on the wishlist). To be continued.
-
- KVRAF
- Topic Starter
- 12740 posts since 24 Jun, 2008 from Europe
There is a new MuLab 6.4.11 test version in http://www.mutools.com/forsythia/
Changes since M6.4.10:
OSX: Simply replace the MuLab.app by the new version.
Windows: Simply replace the MuLab.exe + MuLab.ID files by the new versions.
Changes since M6.4.10:
- Multi-Point Envelope, Note Mapper and WaveShape editors now also have a preset name display and previous/next preset buttons so to easily navigate thru the library presets.
- The "Select Previous Preset" and "Select Next Preset" shortcut functions now also work for Multi-Point Envelope, Note Mapper, WaveShape and all other types that use preset files.
- LFO editor: Improved automatic refresh of the waveshape list, eg also in case you saved a new user library wave shape.
- Inserting an effect in one of the MuSynth FX slots resized that slot. Fixed.
- Dropping a VST DLL file on the [+] track button now creates a new track for a new rack with that VST plug-in.
- When loading a new preset file into the Multi-Point Envelope the editor window title was not updated. Fixed.
- Note Mapper editor: "Input" and "Output" labels were not displayed right. Fixed.
- The Virtual MIDI Keyboard can now also be set to match a QWERTZ keyboard layout and also a fully user defined key setup is supported now.
- Fixed an issue when editing numeric pitch-bend values.
- Sequence editor: When inserting a note, the property panel shows the data for that note, but when undoing the insert, the property panel was not cleared. Fixed.
- Sequence editor: Changing aftertouch and pitch-bend values via the property panel was not working correct. Fixed.
OSX: Simply replace the MuLab.app by the new version.
Windows: Simply replace the MuLab.exe + MuLab.ID files by the new versions.
-
- KVRist
- 319 posts since 13 Sep, 2011 from UK
I'd like this also as we currently have to do some manual 'clearing up' when removing a track. Also, when the rack is deleted, so are the associated modules/vsts in the rack. I understand this this may go against the modular nature of MuLab, so maybe an option in the preferences to switch it on or off?runaudio wrote:Great update but i wish when you delete a track it also deletes the rack as well may be on next update
-
- KVRAF
- 7137 posts since 8 Feb, 2003 from London, UK
Tracks are not 1:1 with racks. More than one track can target the same rack. What should happen? You delete one track, the rack goes and then all the other tracks get deleted that were targeting that rack? That doesn't sound like the right thing at all.
-
- KVRist
- 319 posts since 13 Sep, 2011 from UK
I'd have an option in preferences to switch this on or off. If on, when you delete a track have a 'do you want to delete the associated rack' yes/no? If you select yes, other tracks that were associated with that rack are kept for you to manually attach to other racks/vsts. I can see this may be controversial here. I can live with it how it is, but my personal workflow is often, but not always 1:1 track-rack. Not a deal breaker.pljones wrote:Tracks are not 1:1 with racks. More than one track can target the same rack. What should happen? You delete one track, the rack goes and then all the other tracks get deleted that were targeting that rack? That doesn't sound like the right thing at all.
Last edited by mgiambro on Fri Mar 20, 2015 9:42 am, edited 1 time in total.
-
- KVRAF
- Topic Starter
- 12740 posts since 24 Jun, 2008 from Europe
I understand that this is about two different visions / workflows. Currently it is very free and modular, which has creative advantages. There are ideas floating around to also support a more straightforward 1:1 concept, without giving up the modular freedom, but that's still in brainstorming phase.
-
- KVRist
- 319 posts since 13 Sep, 2011 from UK
Pleasing everyone is never going to be easy, but you're doing a fine job thus far. I'm just adding my personal two-penneth. I fully understand the argument of keeping the rack if multiple tracks are assigned to it, but do think that the option of cleaning up in certain conditions will speed up workflow for some. Who'd be a developermutools wrote:I understand that this is about two different visions / workflows. Currently it is very free and modular, which has creative advantages. There are ideas floating around to also support a more straightforward 1:1 concept, without giving up the modular freedom, but that's still in brainstorming phase.
.-
- KVRAF
- 7137 posts since 8 Feb, 2003 from London, UK
Just to throw another couple of examples in based on my workflow.
If you're A/B-ing a couple of different set ups of different sound processing for a track, switching the track between two racks is an easy way to do it. That's a clear case where you can't just delete a rack because it's no longer referenced by a track.
I just think of rack as "sound" and track as "player" - the same sound could be played at different times by different players. I might set up a sound, change my mind against using it where I'd started to, then come back to it later somewhere else. Getting sounds "right" takes me more time usually than getting what's playing them right, so I'm less likely to want to lose them. Players are more usually arrangements of repeated, shared sequences - "cheap" - or long audio files (likely to be "fixed"). I might delete tracks whilst doing this but I'd definitely not want a rack deleted.
(I only save out to presets stuff that'll be reused between projects - I like not to reuse sounds...)
EDIT:
Actually... what I'm trying to model is this.
Each track is the "raw" sound of one player playing an instrument. Each player might play the same instrument differently, of course, so you need settings per track.
Each rack is the "captured" sound of one microphone. Each mic might be processed differently and one or more players might share a mic. Indeed, a player might switch mics during a performance.
So in my ideal model, a track outputs sound - rather than events. Thus a sequence track has a single slot for an instrument (it also supports automation of that slot). I'd also like to automate the track target, so I could change "mics" during performance.
(You could still get events out of a sequence track if you didn't put an instrument in the slot, of course.)
If you're A/B-ing a couple of different set ups of different sound processing for a track, switching the track between two racks is an easy way to do it. That's a clear case where you can't just delete a rack because it's no longer referenced by a track.
I just think of rack as "sound" and track as "player" - the same sound could be played at different times by different players. I might set up a sound, change my mind against using it where I'd started to, then come back to it later somewhere else. Getting sounds "right" takes me more time usually than getting what's playing them right, so I'm less likely to want to lose them. Players are more usually arrangements of repeated, shared sequences - "cheap" - or long audio files (likely to be "fixed"). I might delete tracks whilst doing this but I'd definitely not want a rack deleted.
(I only save out to presets stuff that'll be reused between projects - I like not to reuse sounds...)
EDIT:
Actually... what I'm trying to model is this.
Each track is the "raw" sound of one player playing an instrument. Each player might play the same instrument differently, of course, so you need settings per track.
Each rack is the "captured" sound of one microphone. Each mic might be processed differently and one or more players might share a mic. Indeed, a player might switch mics during a performance.
So in my ideal model, a track outputs sound - rather than events. Thus a sequence track has a single slot for an instrument (it also supports automation of that slot). I'd also like to automate the track target, so I could change "mics" during performance.
(You could still get events out of a sequence track if you didn't put an instrument in the slot, of course.)
-
- KVRist
- 180 posts since 19 May, 2009 from UK
There's already a "delete unused tracks" option - maybe just have a "delete unused racks" as well
Talking about workflow - my pet FR at the moment would be for all parts to start with a default loop (as shown in the editor screen) - that would cover the whole part.
This would negate the need to have to keep defining loops to repeat a part - as most of the time you want the whole part repeated
Talking about workflow - my pet FR at the moment would be for all parts to start with a default loop (as shown in the editor screen) - that would cover the whole part.
This would negate the need to have to keep defining loops to repeat a part - as most of the time you want the whole part repeated
Cheers
Mick
Mick
