TK.
-
Posts
15,246 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
This option would require a major redesign of the entire application: the MIDI functions have to be strictly separated from GUI elements to make this possible.
You know where to find the source code... ;-)
Btw.: an example for command line parsing can be found in the source code of MIOS Studio.
But it doesn't fulfill your request, because it's handled at a place where the DocumentWindow is already opened (it will be immediately closed in --batch mode), this simplified a lot of things.
So: you need to find a different way.
I also don't know how to specify the --config file - maybe a google search will help you to find the required information.
Best Regards, Thorsten.
-
Here a new version with Screen Saver and support for CLCD_PP:
http://www.ucapps.de/mios32/midibox_seq_v4_088_pre5.zip
The Screen Saver will be activated after 30 minutes.
The time can be changed in the UTIL->OPT menu (here it can also be disabled)
For testing it can be directly activated by entering "screen_saver" in MIOS Terminal
Best Regards, Thorsten.
-
I have used the relatively new option to define the maximum number of shift registers (SRIO num_sr=16)
Please note that there was a problem with the SRIO num_sr function in V1.032
There is a newer version (v1_033_pre4) which can be downloaded here: http://www.ucapps.de/mios32/
However, I don't know if this will fix your issues...
The script was fired on a button press. But rather than seeing a delay of 1 sec between the two messages I saw only half a second. Could it be that the delay_ms is somehow coupled to the defined number of shift registers and that by halving that my delays halve as well?It shouldn't... I never tried such a high delay by myself, will try this soon...
Another thing I noticed is that if I press the button while the previous script is still running it seems to abort the script and start it again. Is that intended behaviour?Yes, this is the intended behaviour.
Commands won't be queued.
Now the things I'm worried about. I have 43 of those SAMs and a lot of commands can come in in quick succession.I fear that there is currently no way to do such kind of automation with MIDIbox NG :-/
And I've currently no idea for a simple implementation.
My biggest problem is, that I don't have access to your equipment for testing ;-)
Best Regards, Thorsten.
-
Is there a preferred method for determining the number of the track that's currently being worked with from within, for example, SEQ_CORE_ScheduleEvent()? Can the current track number be determined from a seq_core_trk_t or seq_cc_trk_t object? ...or should I just pass the track number to SEQ_CORE_ScheduleEvent() as an argument if it's needed?
The right way would be to pass the track number to this function as an argument (API has to be changed)
Are there Doxygen documents specifically for the SEQ like there are for the NG?You could create one with Doxygen
Here the config file for MBNG: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fdoc%2F
The robotizer seems to add +18 uS or less compared to just having Echo, sustain, and duplicate on.well done! :)
Best Regards, Thorsten.
-
I fear that there is no easy way to solve this.
Best Regards, Thorsten.
-
Nobody reported such an issue before, therefore I've no spontaneous idea what could cause this.
The environment variables look ok.
Are you trying this with an unmodified SVN repository? (I guess: yes, of course...)
It seems that the programming_models/traditional/freertos_heap.cpp file is problematic... but why?
Best Regards, Thorsten.
-
It's not the first time somebody requests this.
Using the on-board Audio DAC is feasible, it will cost a bit performance of the application, but as long as it only outputs a beep it should be ok.
I added this to the wish list for V4 Plus
No, I don't plan to spend too much effort on this topic - beeping ok, playing samples not ok.
Best Regards, Thorsten.
-
In the PIC16F88 based firmware, the IIC_DEVICE_ADDRESS value has to be changed from 0x10 to 0x18 (the value is defined in src/iic.asm)
In the MBSEQ V4 firmware, MIOS32_IIC_MIDI_NUM has to be changed from 4 to 8 in mios32/mios32_config.h
Best Regards, Thorsten.
-
Tabs are handled like whitespaces
Best Regards, Thorsten.
-
Nein, das ist nicht die aktuellste Version.
Ok, in der aktuellen wird J5 noch erwaehnt, doch dort stehen jetzt auch die neuen SRs bereit, und das User Manual geht nur noch darauf ein.
Wenn Du diesen Artikel abonnierst, wirst Du uebrigens automatisch ueber Updates per Email informiert:
Gruss, Thorsten.
-
Die J5 Ausgaenge sind veraltet, bitte nicht mehr verwenden, denn sie liefern nur 3.3V fuer das Signal, und ohne spezielle Schutzschaltung kannst Du den Mikrocontroller zerschiessen!
Stattdessen nur noch DOUTs hernehmen, hier stehen die Gates mit 5V zur Verfuegung.
Siehe auch http://www.ucapps.de/midibox_seq_manual_hw.html
Ganz unten
Dort steht auch die Zuordnung fuer die 64 zusaetzlichen Trigger beschrieben.
Wo hast Du J5C aufgeschnappt? Diesen Port gibt es ja nur beim MBHP_CORE_STM32, doch ich erwaehne ihn schon gar nicht mehr im Manual...
Gruss, Thorsten.
-
And I got the OLEDs today.
Observations:
- same behaviour at my side when OLEDs connected to a STM32F4 core
- OLED was working when I connected a common LCD to J15B instead of the second OLED
- both OLEDs are working together on a LPC17 core
In the app_lcd driver I found the difference between STM32F4 and LPC17: for LPC17 the pins which drive E/RW/RS are always configured in Push-Pull (PP) mode, for STM32F4 these pins are configured for Open-Drain mode (they are pulled to the LCD voltage with external pull-up resistors).
The LPC17 variant was actually a workaround for a weakness in the LPC17 microcontroller.
However, I added a new CLCD type "CLCD_PP" which will configure the pins in Push-Pull mode instead of Open Drain
Observations:
- OLEDs still failing at 5V LCD voltage
- but OLEDs are working at 3.3V LCD voltage!
-> solution found! :-)
And an explanation as well: the datasheet specifies an VIH (input high) level of 0.9 * VDD, which can't be achieved via the pull-up resistors when more than one OLED is connected to the same pin.
By reducing VDD to 3.3V, and setting the pins in the "stronger" push-pull mode, the spec isn't violated anymore accordingly displays are working properly.
@cube48: I will send back the OLEDs tomorrow, you may receive them saturday - be prepared for a nice weekend! :-)
The new CLCD_PP type has to be configured in the bootloader with "set lcd_type CLCD_PP".
As long as no new bootloader has been released, you can also set it with "set lcd_type 0x02", which has the same effect.
In addition, you will need a new MBSEQ V4 release which will be available saturday as well - maybe together with the screen saver ;-)
Best Regards, Thorsten.
-
No other idea; try to find out the logic behind the observed behaviour.
In order to transfer 16 bits (= 2 * u8) just call the MIOS32_SPI_TransferByte function two times between the RC1 activation/deactivation.
You are already doing this in the code that you've showed in the first posting.
Btw.: the PGA2311 specifies 8 bits per volume level, but your value only ranges between 0..127 (=7 bit)
This is not the reason for the behaviour, but it makes sense to change the range from 0..255 anyhow
Best Regards, Thorsten.
-
It depends on the microcontroller which is connected to the SPI device.
Modern microcontrollers are typically supplied at 3.3V, but they have 5V tolerant inputs -> no voltage reduction required.
For level shifting (3.3V -> 5V) a 74HCT based buffer is sufficient, see also the MBHP_CORE_STM32F4 schematic (http://www.ucapps.de/mbhp/mbhp_core_stm32f4.pdf) where I'm using a 74HCT541 to shift the outputs levels of two independent SPI ports from 3.3V to 5V
I don't know any MIDIbox which requires more than 5V at the SPI port ;-)
Best Regards, Thorsten.
-
Do you want to connect it to a MIOS32 based core?
In this case the solution would be easy: use J16 for 3.3V supply, or J19 for 5V supply
Best Regards, Thorsten.
-
What is the screensaver doing, just printing some text on the screen?
The existing MBSEQ V4 boot screen might be a nice solution for this; just to turn it on after a configurable time until a control element is moved.
Actually the idea of this pseudo-graphic during boot is borrowed from the screen saver of a Waldorf Micro Q, I already considered to use it as a real screen saver as well :)
Best Regards, Thorsten.
-
What sort of stopwatch +uS number should I be aiming for on the LPC core?
Than lower than better. ;-)
But don't spent too much time on this optimization step, it can be counter-productive.
...also, with the long random number thing: I'm thinking that if I take bits 1-10, 2-11, 3-12, etc., I could take a lot more than 3 pseudorandom sequences out of a 32 bit number... I think they'd all be more or less random enough, especially if I used them in different parts of the robotizer.No good idea, take separate parts to avoid any dependency.
What should I pass as the seed to SEQ_RANDOM_Gen?0 (so that the previous seed won't be overwritten)
Best Regards, Thorsten.
-
Is that reasonable processor time for a function like this?
There is always room for improvements ;-)
E.g. you are writing:
//exit if there's no chance of robotizing anything if( ! tcc->robotize_active || tcc->robotize_probability == 0 || ( !tcc->robotize_vel && !tcc->robotize_len && !tcc->robotize_note && !tcc->robotize_oct && !tcc->robotize_skip_probability && !tcc->robotize_sustain_probability && !tcc->robotize_nofx_probability && !tcc->robotize_echo_probability && !tcc->robotize_duplicate_probability ) ) return returnflags; // nothing to doThis kind of check isn't required, because with the tcc->robotize_active switch you've already ensured that the function doesn't consume time if it isn't activated.
It will only be enabled if the user intends to use the function, and then it's unlikely that he doesn't set one of the parameters.
Please reduce this check to "if( !tcc->robotize_active || !tcc->robotize_probability )", this should be sufficient.
Would it be more efficient if I pulled a long (say 64 bit) random number only once, and then used bit sequences within that long number as my random numbers later in the robotizer function?Yes, it makes sense to reduce the number of SEQ_RANDOM_Gen() calls
It will return a 32bit number
Since you need a range from 0..1023 (=10 bit), you could extract 3 random numbers out of the 32bit value
It doesn't make sense to work with 64bit numbers here...
Best Regards, Thorsten.
-
I appreciate this project a lot - finally a standardized controller surface :smile:
Please add more buttons and LEDs, you can never have enough to switch between different functions on your synth, to trigger something (like a .NGR script), or whatever.
I don't see a way for MBCV V2 support, but I also don't find it necessary.
I think it's better to work on a dedicated solution for MBCV V2 instead.
MBCV V2 uses a special LCD driver mode which allows to access a 2x20 CLCD and 4 OLEDs from the same core. This is a dedicated hack and neither universal (e.g. it isn't supported by MBNG) nor scalable (1 CLCD and 4 OLEDs is the limit for MBCV V2, and the OLEDs can only be used as scopes)
Best Regards, Thorsten.
-
If you send me the OLED displays, I can analyse the problem at my side and ensure future compatibility.
Of course, I will send them back after testing/troubleshooting.
Best Regards, Thorsten.
-
Looks like this could work.
Only the BLM port is problematic, because actually this is one of the MIDI IO ports for which you've already 2 MBHP_MIDI_IO boards.
Best Regards, Thorsten.
-
Unter http://www.ucapps.de/mios32_download.html gibt es eine iic_midi Test-Applikation, die evtl. weiterhilft (siehe README)
Gruss, Thorsten.
-
1) The PGA2311 is not having increasing/decreasing steps when I turn my encoder, even if the variable "value" increases/decreases 1 by 1... :sick:
Instead, I get the PGA2311 obviously hopping between values out of the row, it seems to be a random order.
I guess that the chips expects the MSB first, which means that the byte has to be mirrored.
Please try:
MIOS32_SPI_TransferByte(2, mios32_dout_reverse_tab[Sendbyte])
this should do the trick
2)The PGA2311 is not reacting very reliable to the function MIOS32_SPI_TransferByte. I need to execute the function twice to get a reasonable return value (e.g. 0x7F). :rofl:
3)
The readbyte (as a return of the function MIOS32_SPI_TransferByte) is not corresponding correctly to the value that has been set. Furthermore it returns the value that has been set in the last call of the function. Thats confusing me. Any hints? :question: :question:
that's the normal shift register behaviour, it can't shift out the value which is currently shifted in.
It will be shifted out with the next transaction.
Best Regards, Thorsten.
-
You shouldn't change anything in the mios32_midi.h file!
And please never start such modifications outside your own application to prevent a big disaster ;-)
The "midi_package.chn == 9" is part of your own code.
I'm surprised that you can't find it there - just search this keyword in your initial posting.
It's even part of the subject.
I proposed that you replace the 9 by Chn10 to improve the readability, nothing else.
Just try it out - it works! :smile:
Best Regards, Thorsten.
P.S.: I will avoid to give you background informations in future, they confuse you too much.
Sharing Wilba SEQ control surface with NG...
in MIDIbox NG
Posted
Here a configuration example for the MBSEQ Frontpanel PCB: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftk%2Fmbseq.ngc
Reconnecting LCDs on the fly will require that you trigger the RESET button (black button on the STM32F4DISCOVERY module)
Best Regards, Thorsten.