TK.
-
Posts
15,198 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
This display won't work because:
- it isn't supported by MIOS32
- graphical LCDs are not supported by the MBSEQ V4 application
- the screen dimensions are not supported by the MBSEQ V4 application
- the 80x2 character row would be hard to read with this small size
-> bad choice
Best Regards, Thorsten.
-
Du hast Dir da ziemlich viel fuer den Anfang vorgenommen...
Also können z.b 2 Core über usb nebeneinander arbeiten als quasi ein Controller?Das kommt darauf an, wie Du den Controller an die DAW koppelst.
Anfangs hast Du noch Mackie Control geschrieben, nun haben die Kanaele ploetzlich 8 Encoder pro Kanalzug und LED Ringen mit 16 LEDs, das wird aber so vom Mackie Control Protokoll nicht unterstuetzt.
Die 2 OLEDs pro Kanal passt ebenfalls ueberhaupt nicht mit dem zusammen, wie die DAW das Display einer Mackie Control ansteuern wuerde.
Am besten erkundigst Du Dich erstmal ueber die Moeglichkeiten Deiner DAW.
Zu den LEDs: die lassen sich ja zu einer Matrix verschalten.
Fuer 8 Encoder mit 16 LED Ringen nimmt man bspw, einen 8x16 Matrix, das sind gerade mal 3 DOUT Shift Register (und bis zu 32 lassen sich hintereinander schalten, hier sollte man jedoch auf die verdrahtung achten, evtl. mit dem MBHP_LINE_DRIVER arbeiten, ein komplexes Thema...)
Nunja, ich wuerde Dir empfehlen, die Sache langsam anzugehen, bevor Du eine Menge Geld versenkst!
Und wichtig: uCApps.de lesen, im Forum suchen, googlen - hier wird Dir nichts mundgerecht vorgekaut! ;-)
Gruss, Thorsten.
-
Servus,
wenn Du in diesem .NGC File nach "MF" suchst, findest Du folgende Zeile:
# we've a single MBHP_MF_NG module with 8 motorfaders # It has to be configured for Motormix protocol! MF n=1 enabled=1 midi_in_port=IN3 midi_out_port=OUT3 chn=1 ts_first_button_id=2001 config_port=USB3
hier ersetzt Du IN3 durch IN2 und OUT3 durch OUT2
Wie aus dem Kommentar ersichtlich, muss das Motormix-Protokoll (und nicht das Mackie Protokoll) konfiguriert werden - die Konversion nach Mackie uebernimmt die MBNG.
Falls dann noch notwendig, kann das Modul kann anschliessend ueber die USB3 IOs konfiguriert werden (wird mit config_port=USB3 vorgegeben)
Gruss, Thorsten.
-
Hallo Boris,
mit der MIDIbox NG kann man das alles mit einem einzigen 32bit Core bedienen: http://www.ucapps.de/midibox_ng.html
User Manual: http://www.ucapps.de/midibox_ng_manual.html
Und wenn ein 32bit Core immer noch nicht ausreicht, kannst Du mehrere kombinieren. Am einfachsten ueber einen USB Hub.
Hier gibt es eine eigene Forum Sektion fuer dieses Projekt: http://midibox.org/forums/forum/46-midibox-ng/
Wenn Du dort suchst, wirst Du auch Erfahrungsberichte ueber das Anschliessen von mehreren LCDs finden - es ist nicht immer so einfach, wie man denkt, aber es geht! ;-)
Gruss, Thorsten.
-
This configuration will only set the value of the LED, but it won't trigger the action (it won't execute the meta command)
For such purposes I introduced the SENDER event; so if you write:
#should forward when incoming signal is the correct channel, correct cc and value=0 EVENT_RECEIVER id=1 fwd_id=sender:33 type=CC chn=5 cc=1 range=0:0 #should forward when incoming signal is the correct channel, correct cc and value=127 EVENT_RECEIVER id=2 fwd_id=sender:34 type=CC chn=5 cc=1 range=127:127 # run section 1 EVENT_SENDER id=33 type=Meta meta=RunSection:1 # run section 2 EVENT_SENDER id=34 type=Meta meta=RunSection:2
the run script section should be executed.
From the section you can switch the LED, e.g. "set LED:33 127" will turn it on, and "set LED:33 0" will turn it off
Best Regards, Thorsten.
-
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.
-
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.
PGA2311 STM32F4 HowTo?
in MIOS programming (C)
Posted
The MIOS32_SPI_TransferBlock callback isn't required for this use case, it's typically used if the app want's to send a higher amount of bytes (e.g. 64 bytes and more) and shouldn't wait until the bytes have been transmitted, but should execute the callback function instead to notify, that a new block could be sent.
However, while you post this: it could make sense to try out different speeds and transfer modes.
Try out following configurations:
or
or
or
or
or
or
or
Best Regards, Thorsten.